„Odmowa dostępu” do pliku, którego jestem właścicielem?

Mój użytkownik, Bob, nie ma dostępu do plików, które on (teoretycznie posiada). Korzystam z Fedory Core 8. Prawdopodobnie łatwiej jest pokazać niż powiedzieć:

> 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

ls -alWyróżnia się bardzo dziwne. Wyświetli listę plików, których nie mam uprawnień, aby zobaczyć, ale nie pokaże mi uprawnień?

Pytanie brzmi: co by to spowodowało? Co mogę zrobić, aby to naprawić?

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

Wygląda na to, że Bob nie ma uprawnień do wykonywania ./log, więc nie może tego cdzrobić.

Ale

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

pokazuje, że tak. Ale nie wygląda na to, że wskazują na ten sam plik (różne uprawnienia, inny czas modowy).

Spróbować sudo ls -ail ./logi ls -ailzobaczyć, czy i-węzeł jest taka sama.

Sprawy są prostsze niż uszkodzenie systemu plików lub selinux. Jak widać, brakuje Ci uprawnienia x (wykonywalnego) do katalogu dziennika. W rzeczywistości dla katalogów x oznacza, że ​​ktoś może przejść do tego katalogu. Po prostu zrób „chmod + x log”, aby naprawić to zezwolenie i powinieneś być w stanie uzyskać do niego dostęp.

Widziałem takie rzeczy, gdy system plików został uszkodzony lub jeśli masz uszkodzony dysk. Naprawą jest zazwyczaj uruchomienie fsck przeciwko systemowi plików i umożliwienie poprawienia znalezionych błędów.

Sprawdź także ustawienia SE / Linux. Czasami uprawnienia do pliku nie mają nic wspólnego z tym, czy masz do niego dostęp.

Pliki mogą mieć niezmienne lub dołączać tylko rozszerzone atrybuty. Zdarzyło mi się to wcześniej i nawet root nie mógł usunąć pliku.

Rozszerzone atrybuty mogą być widokami za pomocą „lsattr” i zmieniane za pomocą „chattr”

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

Nie jestem pewien dlaczego, ale „.” wpis w ./log/ nie ma uprawnień do wykonywania. Uprawnienia powinny być identyczne z uprawnieniami dla ./log.

Czy możesz spróbować chmod 755 ./log i chmod 755 ./log/. i sprawdź, czy któreś polecenie naprawia dostęp?

Poza tym radzę uruchomić fsck w systemie plików, ponieważ wygląda na to, że nie jest zsynchronizowany.

Czy próbowałeś zmienić własność katalogu na inną osobę, a potem z powrotem na Boba? Porada Zoredache jest jednak lepsza - po prostu ją sprawdź!

Bardziej zwięzła odpowiedź IMO.

Twój katalog nie ma uprawnień do wykonywania, które są wymagane przez cd .

Naprawić:

$ sudo chmod +x ./log

Rekurencyjnie:

$ sudo chmod -R +x ./log

+ x dodaje atrybut wykonywalny. Zawsze możesz usunąć atrybut, wykonując -x