使用 Systemd 定時器可靠地執行 ownCloud 後台作業
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
「PAM 驗證失敗」訊息並沒有提供通用的解決方案。首先要確定是哪個服務和使用者發生故障,然後檢查對應時間點的日誌。在 SUSE Linux Enterprise Server (SLES) 上,如果已確認有全域 PAM 問題,請透過 `pamconfig` 指令進行修復pam-config,僅當某個服務的堆疊出現問題時才修改該服務的設定檔。測試時,請保持一個可用的 root 使用者或管理員會話處於開啟狀態;損壞的 PAM 堆疊可能會阻止新的 SSH 和控制台登入。
目前的 SLES 15 SP7 安全性增強指南將 PAM 描述為由身份驗證、帳戶、密碼和會話模組組成的堆疊。這種區分至關重要:即使密碼正確auth,也可能在後續階段被帳戶原則或特定於服務的規則拒絕。僅憑通用的錯誤訊息無法確定是哪個階段失敗了。
PAM 在應用程式(例如sshd控制台登入)和已設定的身份驗證方法之間進行協調。每個支援 PAM 的服務都有一個 PAM 檔案/etc/pam.d/。此服務文件可能包含 SLES 通用文件,例如 `<service-file>`common-auth和common-account`<service-file>`,因此,SSH 獨有的故障原因可能與所有登入方法的故障原因不同。
已驗證: SUSE 文件中記錄的 SSH 協定堆疊包含pam_nologin.so常用的 PAM 檔案。如果/etc/nologin存在,文件中記錄的模組會拒絕 root 使用者以外的其他使用者登入。上下文相關:本地編輯的規則、目錄服務和第三方 MFA 模組可以添加更多檢查。僅憑訊息無法確定:密碼錯誤、PAM 檔案損壞或帳戶已被鎖定。應先檢查受影響的服務及其日誌,而不是替換整個協定堆疊。
請重現故障一次,並記錄時間、使用者名稱和登入方式:SSH、本機文字控制台、圖形介面登入sudo等su。如果您可以以管理員身分登入,請檢查最近的系統訊息:
sudo journalctl -e
SUSE 的 SLES 故障排除指南特別建議檢查日誌中的登入和 PAM 錯誤。在嘗試登入的確切時間附近尋找模組名稱或錯誤原因,例如帳戶被拒絕、目錄服務不可用、模組缺失或檔案/權限錯誤。切勿在未刪除使用者名稱、主機名稱、地址和其他敏感資訊的情況下公開分享日誌。

如果只有 SSH 連線失敗,請檢查 SSH 守護程式的日誌:
sudo journalctl -u sshd

然後比較訪問路徑。如果使用者可以透過本機控制台進行身份驗證,但無法透過 SSH 進行身份驗證,則專注於檢查/etc/pam.d/sshdSSH 存取原則或 SSH 特定模組。如果多個服務拒絕同一本機使用者的訪問,請檢查其共用common-*檔案。如果只有一個使用者失敗,請在變更系統級身份驗證之前驗證帳戶狀態和密碼。
對於本機用戶,請先檢查用戶名、鍵盤佈局和大小寫鎖定鍵。如果需要重設憑證,請使用管理員批准的密碼管理工具(例如 YaST 使用者和群組管理工具),而不是/etc/shadow手動編輯。如果所有非 root 使用者都無法透過 SSH 訪問,請在更改 PAM 之前檢查是否存在計劃維護文件/etc/nologin;僅當確認維護區塊已過期且您已獲得授權時,才能將其刪除。
對於 LDAP、Active Directory 或其他基於目錄的用戶,在其他伺服器上使用有效密碼並不能證明此 SLES 主機可以存取身分提供者。 SUSE 列出了網路和 DNS 問題、Kerberos 時鐘漂移、PAM 規則配置錯誤、主機存取原則以及主目錄不可用等可能的原因。測試其他網域使用者是否可以登入,以及受影響的使用者是否可以登入其他主機。然後檢查配置的身份服務和伺服器連線。
當主機使用 SSSD 時,檢查其服務以及 PAM 是否已配置為使用該服務:
systemctl status sssd
sudo pam-config --query --sss

SSSD 可以快取使用者訊息,並在目錄暫時無法存取時允許身份驗證,但此行為取決於其配置和快取的憑證。因此,緩存過期或缺失只是一種可能性,而非最終結論。在清除任何快取或更改模組之前,請檢查 DNS、Kerberos 時間同步、目錄可及性以及 SSSD 日誌。如果身分提供者報告“帳戶已鎖定”或“帳戶已停用”,請目錄管理員檢查該帳戶的策略;PAM 只是報告決策,並非一定由 PAM 制定。
檢查特定於服務的文件及其包含的共用規則:
sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss

在 SLES 系統中,pam-config全域檔案保存在 `<path>` 下/etc/pam.d/common-*;各個服務檔案(例如`<service-file> /etc/pam.d/sshd`)則是單獨維護。除非您已明確停用某些公開文件,否則請勿手動編輯產生的公開文件pam-config。如果您確認此主機應使用 SSSD 但缺少其 SSSD PAM 規則,請參考 SUSE 文件sudo pam-config --add --sss新增這些規則。僅在確認 SSSD 本身已配置並運行後才可使用此方法,然後在目前管理工作階段保持開啟的情況下測試新的登入。
一個常見但危險的誤解是,這pam-config --create是一個無害的修復命令。 SUSE 表示,它會建立一個基本的 Unix 驗證配置,並覆寫它不管理的現有文件,但會保留備份副本。這可能會移除自訂 MFA 或目錄驗證功能。請勿將其作為通用恢復步驟運行。如果是服務文件中的拼字錯誤,請從可信任備份中還原該服務已知良好且版本相符的配置,或依照貴組織的變更流程修改特定的錯誤行。
保持原有的 root 或管理員會話處於開啟狀態。透過失敗的相同服務(例如新的 SSH 連線)啟動第二個會話,並測試受影響的帳戶。確認日誌中不再記錄相同的 PAM 拒絕,並且其他已設定的身份驗證方法仍然有效。如果故障仍然存在,請擷取確切的時間戳記、服務、PAM 模組名稱以及相關的已脫敏日誌行;這些詳細資訊比通用的「驗證失敗」訊息更有用。
pam-config.將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
透過 Apache、Nginx 或反向代理程式追蹤 WebDAV 請求,然後使用經過驗證的 PROPFIND 測試確認 ownCloud 同步功能正常。
透過設定其規範 URL 並從伺服器本身檢查 DNS、HTTPS 和反向代理路由,修復 Nextcloud 缺少出站位址警告的問題。
透過本機 Unix 套接字配置 APCu 和 Redis,以實現 Nextcloud 快取和檔案鎖定,並提供目前和舊版 Nextcloud 的步驟。
檢查 Nextcloud 的 cron 模式,修復其 systemd 服務和計時器,並驗證後台作業在啟動後以及每隔五分鐘運行一次。
啟用可靠的 Nextcloud 檔案鎖定,選擇適當的 Redis 或 Valkey 後端,並驗證警告是否清除,同時避免並發檔案變更的風險。
使用最新更新、HTTPS 和 HSTS、精確的反向代理信任以及針對公共伺服器的檢查,修復 Nextcloud 掃描中常見的錯誤。
為需要加密的儲存配置 Nextcloud SSE,保護加密金鑰,並在加密現有文件之前測量傳輸和 CPU 影響。
將 Nextcloud 的檔案搜尋連接到 Elasticsearch,索引文件內容,並選擇適合您的伺服器和安全需求的設定。
配置 Nextcloud 在規定的保留期後刪除已刪除的文件,可靠地安排後台作業,並避免執行清除所有使用者回收站的命令。