Claude多用戶權限翻車：1個腳本救活3個工程師的賬號

凌晨2點，Jeremy的終端彈出EACCES: permission denied時，他以為只是少了sudo。三小時后，整個團隊發現問題的根因完全不在代碼里——而在三個月前某次調試留下的文件歸屬記錄。

Claude Code在Linux多用戶環境下的權限架構，比大多數AI工具都更敏感。它不只是在"運行"，而是在持續讀寫日志、緩存和配置。一旦這些文件的屬主和當前用戶錯位，拒絕訪問就成了必然。

癥狀：不是權限不夠，是文件"認錯了主人"

Jeremy的報錯信息很干凈：syscall "open"失敗，errno -13。按常規思路，他檢查了~/.claude目錄的權限——700，屬主admincostplus。問題是他自己就是jeremy，不是admincostplus。

真正詭異的是，這個目錄明明在jeremy的家目錄下，屬主卻是另一個賬戶。Claude Code嘗試往~/.claude/debug寫日志時，系統直接攔住了。

時間線倒推：三個月前，admincostplus賬號曾在jeremy的家目錄下運行過Claude Code。當時為了排查問題，用了root權限或者切換用戶的方式啟動。結果創建的文件和子目錄，全部帶上了admincostplus的屬主標記。

jeremy對自己的家目錄有讀權限，但對admincostplus創建的文件沒有寫權限。Claude Code的日志模塊一啟動就崩潰，整個程序跟著掛掉。

用--dangerously-skip-permissions跳過檢查？沒用。這個flag只是跳過Claude自己的權限校驗，真正的EACCES來自操作系統內核。

診斷：三層權限疊加的"幽靈文件"

Linux權限問題的麻煩在于，表面癥狀和根因往往隔了好幾層。jeremy遇到的場景，實際上是三層疊加：

第一層是用戶隔離。Linux的家目錄設計假設每個用戶獨立運作，Claude Code卻需要在多賬戶間共享配置和對話歷史。這個張力從架構層面就存在。

第二層是歷史遺留。admincostplus之前運行產生的文件，成了jeremy家目錄里的"釘子戶"。ls -la /home/jeremy/.claude/debug/顯示drwx------ 2 admincostplus admincostplus——jeremy連進都進不去。

第三層是Claude Code的寫入習慣。它不像傳統CLI工具那樣只讀配置，而是持續追加日志、更新狀態文件。這意味著即使jeremy能"看到"目錄，只要寫操作被拒絕，啟動流程就會中斷。

常見的chmod 777方案為什么被作者明確否定？因為它破壞了審計追蹤，讓后續排查更困難，而且在生產環境屬于安全紅線。

方案：用setgid位做"權限遺傳"

作者給出的生產級腳本，核心思路是建立一個共享組claudeusers，讓文件歸屬從"用戶級"降到"組級"，同時用setgid位（chmod 2775中的2）確保新創建的文件自動繼承組屬主。

腳本分三步走：

第一步建組加人。getent檢查claudeusers是否存在，不存在就groupadd創建。然后用usermod -a -G把jeremy和admincostplus都加進去。-a參數防止覆蓋用戶已有的其他組歸屬，這是生產環境的安全習慣。

第二步創建共享目錄/opt/claude-shared，用jeremy作為屬主、claudeusers作為屬組。chmod 2775里的2就是setgid位，作用類似于目錄的"基因標記"——任何在里面創建的文件，自動帶上claudeusers組身份，而不是創建者的主組。

第三步處理四個關鍵目錄的遷移：.claude、.claude-code、.config/claude-code、.local/share/claude-code。腳本用rsync把jeremy家目錄下的內容同步到共享位置，然后給admincostplus的家目錄建立符號鏈接指向共享位置。

符號鏈接的設計很精巧。admincostplus以后運行Claude Code時，讀寫操作實際發生在/opt/claude-shared，但路徑看起來還是原來的~/.claude。應用程序無感知，用戶也無感知。

備份邏輯也考慮到了：如果admincostplus的家目錄里已經有同名目錄且不是符號鏈接，腳本會把它重命名為.bak-時間戳，防止數據丟失。

執行：為什么必須用root

整個腳本需要sudo或root執行，原因很實際：修改其他用戶的家目錄內容、創建系統級共享目錄、修改用戶組歸屬，這些操作都超出了普通用戶的權限邊界。

作者特意在注釋里寫明"Run as: sudo bash this-script.sh"，因為實際部署中，很多工程師會習慣性地復制粘貼腳本內容，忽略執行身份要求。

一個細節：腳本用了getent passwd "$MASTER_USER" | cut -d: -f6來獲取家目錄路徑，而不是硬編碼/home/jeremy。這在用戶家目錄被自定義到/data或/nfs等位置的環境中能救命。

另一個細節：rsync用了--delete參數。這意味著如果共享目錄里已經有內容，會被jeremy家目錄的版本覆蓋。作者假設jeremy是"主用戶"，admincostplus是"輔助賬戶"，這個假設需要在執行前確認。

如果實際情況相反——admincostplus的配置更完整——就需要交換MASTER_USER和ADMIN_USER的值，或者手動合并配置。

這套方案的價值不在于解決了一個具體的EACCES錯誤，而在于提供了一種可復用的多用戶AI工具權限模型。Claude Code不是第一個遇到這個問題的工具，也不會是最后一個。

當AI編程助手從個人玩具變成團隊協作基礎設施，Linux權限架構的古老智慧——用戶、組、setgid、符號鏈接——反而成了最可靠的解決方案。沒有新發明，只有對現有機制的精確組合。

你的團隊里，有多少個jeremy和admincostplus在共用服務器跑Claude Code？他們的~/.claude目錄，現在屬主是誰？