«Autorisation refusée» pour un fichier que je possède?

Mon utilisateur, bob, ne peut pas accéder aux fichiers qu'il possède (théoriquement). J'utilise Fedora Core 8. Il est probablement plus facile de montrer que de dire:

> ls -al .
total 32
drwxrwxr-x 7 bob bob 4096 May 18 14:33 .
drwxrwxr-x 4 bob bob 4096 May 12 15:44 ..
drwxr-xr-x 2 bob bob 4096 June 1 14:22 log

> cd ./log
-bash: cd: log/: Permission denied

> ls -al ./log
ls: cannot access log/..: Permission denied
ls: cannot access log/the.log: Permission denied
ls: cannot access log/.: Permission denied
total 0
d????????? ? ? ? ?            ? .
d????????? ? ? ? ?            ? ..
-????????? ? ? ? ?            ? the.log

> sudo ls -al ./log
drw-rw-r-- 3 bob bob      4096 Jun  2 04:11 .
drwxrwxr-x 7 bob bob      4096 May 18 14:33 ..
-rw-rw-r-- 1 bob bob         0 Jun  1 04:12 the.log

Le ls -alse distingue comme très étrange. Il listera les fichiers que je n'ai pas les autorisations pour voir, mais ne me montrera pas les autorisations?

Donc, les questions sont, qu'est-ce qui provoquerait cela? Et que puis-je faire pour le réparer?

> sudo ls -al ./log
...
drw-rw-r-- 3 bob bob      4096 Jun  2 04:11 .

Il ne semble pas que Bob ait les autorisations d'exécution pour ./log, il ne peut donc pas le cdfaire.

Mais

> ls -al .
...
drwxr-xr-x 2 bob bob 4096 June 1 14:22 log

montre qu'il le fait. Mais il ne semble pas qu'ils pointent vers le même fichier (différentes autorisations, différents modtime).

Essayez sudo ls -ail ./loget ls -ailvoir si le inode est le même.

Les choses sont plus simples que la corruption du système de fichiers ou selinux. Comme vous pouvez le voir, il vous manque l'autorisation x (exécutable) dans le répertoire des journaux. En fait, pour les répertoires x, cela signifie que quelqu'un peut passer à ce répertoire. Faites juste un "chmod + x log" pour corriger cette perm et vous devriez pouvoir y accéder.

J'ai vu des choses comme ça lorsque le système de fichiers a été corrompu, ou si vous avez un lecteur défaillant. Le correctif consiste généralement à exécuter fsck sur le système de fichiers et à le laisser corriger les erreurs qu'il a trouvées.

Vérifiez également les paramètres SE / Linux. Parfois, les autorisations sur le fichier n'ont rien à voir avec la possibilité d'y accéder ou non.

Les fichiers peuvent avoir l'ensemble d'attributs immuable ou ajouter uniquement étendu. J'ai eu cela avant et même root ne pouvait pas supprimer le fichier.

Les attributs étendus peuvent être des vues via "lsattr" et modifiés via "chattr"

> sudo ls -al ./log
drw-rw-r-- 3 bob bob 4096 2 juin 04:11.

Je ne sais pas pourquoi mais le "." L'entrée dans ./log/ n'a pas d'autorisations d'exécution. Les autorisations doivent être identiques à celles de ./log.

Pouvez-vous essayer chmod 755 ./log et chmod 755 ./log/. et voir si l'une des commandes corrige l'accès?

En dehors de cela, je vous conseille d'exécuter un fsck sur le système de fichiers car il semble qu'il ne soit pas synchronisé.

Avez-vous essayé de changer la propriété du répertoire par quelqu'un d'autre, puis de revenir à Bob? Le conseil de Zoredache est meilleur, cependant - juste le fsck!

Une réponse plus concise OMI.

Votre répertoire n'a pas d'autorisations exécutables, qui sont requises par cd .

Réparer:

$ sudo chmod +x ./log

Récursivement:

$ sudo chmod -R +x ./log

+ x ajoute l'attribut exécutable. Vous pouvez toujours supprimer l'attribut en faisant -x