'Permesso negato' a un file che possiedo?

Il mio utente, bob, non può accedere ai file che (teoricamente possiede). Sto eseguendo Fedora Core 8. Probabilmente è più facile mostrare che 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 

L' ls -al si distingue come molto strano. Elenca i file che non ho permessi per visualizzare, ma non mi mostrano le autorizzazioni?

  • Qual è il modo migliore per impostare un lavoro cron per verificare che un process in corso è ancora in corso e se no, avviarlo?
  • Strano comportmento della storia del bash durante l'esecuzione di più sessioni
  • Come gestire le partizioni montate (fstab + punti di assembly) dal burattino
  • OpenVPN client-to-client
  • L'installazione di Oracle Enterprise Linux non può vedere i dischi locali su HP ProLiant DL360e Gen8
  • Problema Linux di iptables / conntrack
  • Quindi le domande sono, cosa causerebbe questo? E cosa posso fare per ripararlo?

    8 Solutions collect form web for “'Permesso negato' a un file che possiedo?”

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

    Non sembra che Bob abbia eseguito le autorizzazioni per ./log, per cui non è in grado di farlo.

    Ma

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

    dimostra che lo fa. Ma non sembra che puntino allo stesso file (autorizzazioni diverse, modtime differenti).

    Provare sudo ls -ail ./log e ls -ail per vedere se l'inode è lo stesso.

    Le cose sono più semplici della corruzione del filesystem o del selinux. Come si può vedere si manca l'authorization x (eseguibile) nella directory di registro. In realtà per directory x significa che qualcuno è in grado di cambiare in quella directory. Basta fare un "chmod + x log" per fissare quel perm e si dovrebbe essere in grado di accedervi.

    Ho visto cose simili quando il filesystem è stato danneggiato o se hai un'unità in errore. La correzione di solito è di eseguire fsck contro il filesystem e lasciarlo correggere gli errori che ha trovato.

    Inoltre, controllare le impostazioni SE / Linux. A volte le autorizzazioni sul file non hanno nulla a che fare con se è ansible accedervi.

    I file possono avere gli attributi immutabili o appendici solo gli attributi estesi. Ho avuto questo fatto prima e nemless la radice potrebbe eliminare il file.

    Attributi estesi possono essere viste tramite "lsattr" e modificate tramite "chattr"

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

    Non so perché ma "." l'accesso a ./log/ non ha autorizzazioni di esecuzione. Le autorizzazioni devono essere identiche a quelle per ./log.

    Puoi provare chmod 755 ./log e chmod 755 ./log/. e vedere se entrambi i comandi fissa l'accesso?

    A parte questo, vi consiglio di eseguire un fsck sul filesystem perché sembra che non sia sincronizzato.

    Hai provato a cambiare la properties; della directory a qualcun altro, poi torna a Bob? Il consiglio di Zoredache è migliore, però – solo fsck!

    Una risposta più concisa IMO.

    La tua directory non dispone di autorizzazioni eseguibili, che sono richieste da cd .

    Difficoltà:

     $ sudo chmod +x ./log 

    ricorsivamente:

     $ sudo chmod -R +x ./log 

    + x è l'aggiunta dell'attributo eseguibile. È sempre ansible rimuovere l'attributo facendo -x

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.