解決 crontab「BAD FILE MODE」錯誤：檔案權限不當導致排程失效

系統日誌出現 BAD FILE MODE 訊息，導致 cron 拒絕執行對應排程任務，是 Linux 運維常見但易被忽視的問題。本文剖析錯誤成因、定位步驟與修正方案，並延伸說明 /etc/cron.d/、/var/spool/cron/ 等排程檔案的權限規範與最佳實踐。

錯誤現象與日誌範例

Apr 16 11:26:01 jb51.net crond[28354]: (*system*) BAD FILE MODE (/etc/cron.d/flushhost)
Apr 16 11:26:01 jb51.net crond[28354]: (root) BAD FILE MODE (cron/root)

crond 啟動時掃描排程檔案，發現檔案模式（權限位）不符合安全要求，直接跳過該檔案，導致排程任務靜默失效——系統不報錯郵件、不留執行紀錄，極易造成「以為備份跑了、實則未跑」的隱性故障。

根本原因：cron 強制的檔案權限規範

為防止惡意使用者竄改系統排程，cron 守護進程對排程檔案強制要求：

案例中 /etc/cron.d/flushhost 權限為 755（含執行位），而 cron.d 目錄下檔案**必須為 644 非執行檔**，故觸發 BAD FILE MODE。

快速定位與修正步驟

1. 檢查日誌確認檔案路徑： grep 'BAD FILE MODE' /var/log/cron（或 /var/log/syslog）
2. 核對檔案權限： ls -l /etc/cron.d/flushhost → 顯示 -rwxr-xr-x（755）
3. 修正權限： chmod 644 /etc/cron.d/flushhost
4. 驗證修正： systemctl reload crond 或等待下一分鐘 crond 自動重掃，再次 grep 'BAD FILE MODE' /var/log/cron 應無新增紀錄。

擴展排查：批次檢查所有排程檔權限

# 檢查 /etc/cron.d/ 下所有檔案
find /etc/cron.d/ -type f ! -perm 644 -ls

# 檢查使用者 crontab 權限
find /var/spool/cron/ -type f ! -perm 600 -ls

# 一鍵修正（謹慎執行，確認無特殊需求）
find /etc/cron.d/ -type f -exec chmod 644 {} \;
find /var/spool/cron/ -type f -exec chmod 600 {} \;

為何僅部分 RHEL 版本嚴格檢查？

早期 cronie（RHEL/CentOS/Fedora 預設 cron 守護進程）版本對 cron.d 權限檢查較寬鬆；自 cronie-1.4.11 起引入 check_file_mode() 強制驗證，導致升級後舊檔案權限不合規即報錯。Debian/Ubuntu 使用 cron (Paul Vixie 版) 亦有類似檢查，但預設套件安裝時會自動修正權限，手動建立檔案時較易踩坑。

最佳實踐：標準化排程部署流程

1. 套件安裝優先： 透過 RPM/DEB 套件部署排程檔，由套件維護者保證權限正確。
2. Ansible/Salt/Puppet 管理： 在配置管理中顯式宣告 mode: '0644' / mode: '0600'。
3. 手動建立檢查清單：
   • 檔案放入 /etc/cron.d/ → chown root:root → chmod 644
   • 使用者執行 crontab -e 自動生成正確權限，避免手動寫入 /var/spool/cron/
   • cron.*/ 目錄下腳本 → chmod 755 並加 #!/bin/bash shebang
4. 監控告警： 將 BAD FILE MODE 關鍵字納入日誌收集規則（Logstash/Filebeat/Promtail），觸發即時告警。

結語

BAD FILE MODE 本質是 cron 守護進程為防止權限提權攻擊而實施的強制存取控制。運維人員只需遵循「cron.d 644、spool/cron 600、cron.* 腳本 755」三條鐵律，並納入自動化部署與日誌監控，即可徹底杜絕此類靜默排程失效風險。