我有一個專案資料夾，它對所有文件都有混亂的權限。我有將所有內容設定為八進制權限 777 的不良傾向，因為它解決了所有與安全無關的問題。然後，FTP 上傳、文字編輯器創建的檔案等都有自己的一組權限，使一切變得一團糟。我決定集中精力，開始按照應有的方式使用權限。
我認為 664 對於我的所有文件和資料夾來說是一個很好的預設值，我只需刪除其他人對私有檔案的權限，並為執行檔添加 +x 即可。
然而，第二次我將專案資料夾更改為 664：
$ sudo chmod -R 664 。 $ls ls: 無法開啟目錄。
這對我來說毫無意義。我具有讀取/寫入權限，並且我是專案資料夾的所有者。我的專案資料夾最左邊的部分ls -l如下所示：
-rw-rw-r-- 1 codemonkey codemonkey ... drw-rw-r-- 5 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... drw-rw-r-- 3 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... -rw-rw-r-- 1 codemonkey codemonkey ... drw-rw-r-- 4 codemonkey codemonkey ... drw-rw-r-- 5 codemonkey codemonkey ...
我認為這與目錄的權限有關，但是什麼？
答案1
需要執行位元來遍歷 *nix 目錄。您無法cd進入沒有執行權限的目錄，如果許多實用程式需要目錄上下文，這會以不明顯的方式影響它們。考慮：
$ cd /tmp
$ mkdir foo
$ echo baz > foo/bar
$ chmod a-x foo
# You can read the contents of the directory, but ls still complains.
$ ls foo
ls: cannot access foo/bar: Permission denied
bar
# You can't read the file because you can't enter the directory.
$ cat foo/bar
cat: foo/bar: Permission denied
所有這一切的原因是 stat() 的工作方式。摘自man 2 stat：
檔案本身不需要任何權限，但在 stat() 和 lstat() 的情況下，需要對通往該檔案的路徑中的所有目錄具有執行（搜尋）權限。
最重要的是，遞歸chmod很少會達到您的預期，並且會對目錄讀取和執行權限造成嚴重破壞，這可能會導致像您這樣的意外結果。始終將目錄權限與檔案權限分開處理，以獲得最佳結果。
答案2
您需要目錄的執行權限。
考慮
sudo find -type d -exec chmod +x {} +
更新：這是我對執行權限的使用的合理化，這顯然很奇怪。
Unix（以及 Linux）幾乎將所有東西都視為檔案。這擴展到磁碟和各種其他設備。它還包括目錄。
傳統的 Unix 檔案系統有一組適用於檔案的權限。因此，當應用於非普通資料檔案的「檔案」時，Unix 設計者必須為每個權限位元找到一些有用的東西。
讓我們考慮一下目錄。最初似乎合理的是，僅使用讀取權限來決定某人是否可以訪問該目錄 - 例如，生成其中的檔案及其大小和日期戳記等的清單。
但是，假設您希望普通用戶能夠運行 /usr/local/bin 中的程序，但不希望他們能夠在 /usr/local 中翻查以查看那裡有什麼。如果您只有讀取權限，則無法阻止此操作。
因此，執行權限（否則是多餘的）用於控制您的 shell 是否允許「遍歷」目錄，我們的意思是，無需再查找即可找到並讀取子目錄的詳細資訊作為一部分的一條路徑。這允許您僅在需要讀取 /usr/local/bin 內容時存取 /usr/local 目錄。
所以/usr/local 上的+x 意味著你可以運行“/usr/local/bin/foo” 但是/usr/local 上的+r 意味著你可以找到/usr/local 中的所有內容，包括誰擁有它，有什麼權限每個檔案都有，它的大小等。
以上是根據模糊的回憶和推測。這可能不完全正確，但我相信它給出了為什麼“執行”意味著“能夠遍歷”的合理想法。