Linux顯示「唯讀檔案系統」？重新掛載前先找出原因

1. 確認失敗路徑背後的檔案系統

針對產生EROFS的路徑執行 `findmnt --target /path/that/failed -o TARGET,SOURCE,FSTYPE,OPTIONS`，不要猜磁碟名稱。util-linux手冊說明--target接受檔案或目錄，並顯示對應檔案系統。準確記錄TARGET、SOURCE、FSTYPE、OPTIONS。命令失敗或目標不明時，先在同一命名空間確認現有父路徑的掛載，再選擇修復裝置。

這能辨認容易誤判的情況：唯讀綁定掛載中的路徑，原位置可能仍可寫；也可能位於不同命名空間的容器、網路檔案系統或唯讀快照。若錯誤發生在容器或服務內，在具備合法管理權限時從同一命名空間檢查；主機看到的狀態可能不是拒絕寫入的狀態。

SOURCE若是遠端匯出、loop裝置、device-mapper磁碟區或快照，應保留其身分。因名稱相似就修復另一實體分割區，可能加重故障。

2. 改變狀態之前保存證據

故障仍存在時記錄掛載及近期核心訊息。唯讀查看命令包括上述findmnt、`journalctl -k -b --no-pager`，及有權限時的 `dmesg`。分享前遮蔽主機名、序號與敏感路徑。沒有systemd則用系統可用核心日誌工具；dmesg -T可讀時間在休眠恢復後可能不準確，保存原始輸出，不編造精確時間順序。

在保存的日誌找第一項相關錯誤，不只看後續「唯讀」訊息。I/O error、journal abort、EXT4-fs error、device reset、link down、multipath failure、write-protected指向不同原因。Red Hat記錄過所有儲存路徑丟失、日誌中止後檔案系統唯讀的實際案例。

系統仍承載重要資料時，先停止非必要寫入，安排備份或故障切換，再嘗試處理。反覆重新掛載不能證明底層路徑健康。

3. 區分哪一層轉為唯讀

刻意策略：OPTIONS含ro，媒體或快照本來不可變，/etc/fstab要求ro，綁定掛載唯讀，或遠端以唯讀匯出共享。應在擁有策略的層修正；本地重新掛載可能只是暫時措施、遭拒或不適用。

保護狀態：日誌出現檔案系統或日誌錯誤。ext4文件將errors=remount-ro描述為出錯後轉唯讀。已發布Linux 6.16程式碼設定緊急唯讀標記而不設定普通SB_RDONLY，並在ext4選項顯示emergency_ro。核對安裝核心的行為；簡單rw欄位或缺少這個較新標記，都不能證明寫入安全。以日誌和實際錯誤為依據。

底層儲存保護或故障：重新掛載報告write-protected，或日誌出現裝置、匯流排、控制器、線材、多路徑、媒體錯誤。先修復或替換故障路徑。檔案系統檢查可能修復中繼資料損壞，不能修好消失的SAN路徑、壞線材或控制器重設。

遠端或虛擬層：NFS、CIFS、FUSE、雲端磁碟區、容器掛載或不可變映像可能因本地磁碟之外的原因回傳EROFS。依對應層的健康及策略證據排查，不套用ext4修復方法。

4. 卸載後使用對應檢查工具

證據指向檔案系統損壞時，安排停機、故障切換或啟動救援環境，以便卸載目標。卸載後再次確認裝置。e2fsck手冊指出，對已掛載ext2、ext3、ext4執行檢查通常不安全；即使名義上唯讀，掛載中的檢查結果也可能無效。

不要將「執行fsck」解讀為「對看似正確的裝置執行fsck -y」。通用前端會呼叫對應檔案系統工具，各類型恢復機制不同。Btrfs文件建議先卸載，並警告不要用--repair，除非有經驗的開發者或使用者建議。查看所記FSTYPE的現行手冊，盡可能備份，並確認操作是否修改中繼資料。

若日誌顯示儲存路徑問題，先穩定路徑再修中繼資料。否則恢復寫入後，已修復檔案系統可能再次損壞。

5. 處理原因後重新掛載，再驗證

確認唯讀不是刻意策略且原因已處理後，使用記錄的準確TARGET，依檔案系統或平台流程恢復寫入。常見本地用法是 `mount -o remount,rw /exact/mountpoint`，但並非萬用修復；遠端、綁定、容器、快照或受管理磁碟區可能不適用。

分層驗證：對同一失敗路徑重新執行findmnt，在指定安全目錄受控寫入一次、讀回並移除；再查看核心日誌有無新增檔案系統或I/O錯誤，觀察正常負載是否復發。

只有目標掛載可寫、測試經sync或應用往返後仍成功、無新增儲存或檔案系統錯誤且唯讀不再回來，才能認定處理完成。若復發，別繼續將重新掛載當修復，應攜帶證據調查裝置、控制器、網路路徑或平台。