使用 Systemd 定時器可靠地執行 ownCloud 後台作業
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
如果 YaST 透過XIO: fatal IO error 11 (Resource temporarily unavailable)SSH 退出,請先嘗試 SUSE 文件中提供的 Qt 解決方法:QT_XCB_GL_INTEGRATION=none yast.ssh。對於已安裝的 SLES 系統和特定的 YaST 模組,請在模組名稱前使用相同的變量,例如QT_XCB_GL_INTEGRATION=none yast2 disk。如果無法開啟任何圖形應用程序,請先修復 X11 轉送:使用 連接ssh -X,檢查遠端 shell 是否具有DISPLAY值,並確認伺服器已啟用 X11 轉送。
SUSE 的 SLES 15 SP7 部署指南詳細記錄了這種 XIO 故障,並提供了 Qt 的解決方法和 ncurses 的替代方案。該部分內容出現在遠端安裝的上下文中,因此請將其作為針對 YaST over SSH 故障的修復方案;它並不能證明所有 YaST 啟動失敗的原因都相同。以下檢查可以將此情況與本機 X 伺服器缺失、SSH 轉送停用或 X 驗證問題區分開來。
X11 轉送透過 SSH 將遠端應用程式的視窗流量傳送到本機上的 X 伺服器。因此,本機電腦需要運行 X 伺服器,且 SSH 用戶端必須請求轉送。在 X11 桌面上,開啟一個新的終端並如下連接:
ssh -X admin@server.example.com
請將帳戶和主機名稱替換為您自己的帳戶和主機名稱。登入後,執行:
echo "$DISPLAY"
類似這樣的值localhost:10.0表示 SSH 設定了轉發顯示。這只是一個範例,並非固定值:顯示編號可能會有所不同。如果輸出為空,請登出並重新連接-X。如果仍然為空,請檢查客戶端 SSH 設定和下一節中的伺服器設定。請勿手動將其DISPLAY設為猜測的值;SSH 會為會話建立一個代理顯示。

如果您在 Windows 系統上使用 PuTTY,請在會話的「連線」>「SSH」>「X11」設定中啟用 X11 轉發,並確保本機 X 伺服器正在執行。 SUSE 的部署指南中明確指出了這項要求。即使 SSH 登入成功,如果本機沒有 X 伺服器,遠端主機也無法顯示視窗。
在 SLES 主機上,管理員可以檢查 SSH 守護程式配置:
sudo grep -i '^X11Forwarding' /etc/ssh/sshd_config
command -v xauth
有效的伺服器策略必須允許 X11 轉發,並且xauth必須可用於身份驗證交接。 SUSE 文件X11Forwarding Yes中將其作為伺服器端設置,並指出 SSH 會DISPLAY在客戶端連線時設定遠端伺服器-X。簡單的grep配置可能會遺漏設定檔或條件區塊中的設定Match;如果輸出結果與實際行為相衝突,請讓 SSH 管理員檢查有效配置,而不是新增重複的行。

如果進行了更改sshd_config,請在重新載入守護程序之前驗證該檔案:
sudo sshd -t
sudo systemctl reload sshd
請務必以管理員身份執行這些命令。測試新會話時,請保持現有 SSH 會話打開,以免配置錯誤導致您無法存取。測試完成後,斷開連線並重新連線;轉送設定在 SSH 會話啟動時進行協商。請勿在伺服器上開啟 TCP 連接埠 6000 或將xhost +其用作捷徑。 SSH 轉送旨在對 X 流量進行隧道傳輸並管理其身份驗證;直接存取 X 可能會顯示內容暴露給其他電腦。
如果DISPLAY已設定且另一個轉送的 X 應用程式打開,但 YaST 出現上述 XIO 錯誤,請嘗試針對該次啟動使用文件中記錄的環境變數覆寫:
QT_XCB_GL_INTEGRATION=none yast.ssh
對於常規安裝的系統,請啟動所需的模組,而不是假設安裝助手程式已存在。例如,SUSE 對此模組表單有詳細說明:
QT_XCB_GL_INTEGRATION=none yast2 disk

此變數僅適用於其後的命令;它不會永久更改 Qt 設定或 SSH 策略。 SUSEyast.ssh的安裝系統使用此指令,而已安裝的 SLES 主機通常會使用此指令啟動 YaST 模組yast2。如果其他模組發生故障,請將 `<module_name>` 替換為其文件中記錄的模組名稱disk。請勿將此環境變數設定視為解決空白DISPLAY或用戶端缺少 X 伺服器問題的方案。
如果您只需要完成管理操作而不需要圖形窗口,請在 SSH 終端機中使用 YaST 的 ncurses 介面。關於磁碟模組,請參閱 SUSE 文件:
yast2 disk --ncurses
您也可以明確地為該模組請求 ncurses 後端:
YUI_PREFERRED_BACKEND=ncurses yast2 disk

文字介面完全避免了 X11 轉發,通常是遠端伺服器最簡單的選擇。它仍然是 YaST,仍然會更改系統配置;在確認更改之前,請仔細檢查磁碟、分割區、防火牆和網路配置。對於 SLES 安裝系統,SUSE 表示,當本地 X 伺服器不可用時,YaST 會提供一個 ncurses 介面。
使用 SSH 開啟新的會話ssh -X,確認會話echo "$DISPLAY"不為空,然後使用對應的指令啟動 YaST。成功表示 YaST 視窗出現在本機桌面上,或者如果您選擇了 ncurses 後端,則 ncurses 模組會在終端機中開啟。如果轉送正常,但在 Qt 覆蓋後仍然存在相同的 XIO 錯誤,請捕獲完整的終端錯誤訊息,並查看 SLES 發行說明或 SUSE 支援知識庫,以查找特定於該版本的問題;僅憑錯誤片段無法識別無關的 Qt 或 YaST 缺陷。
-X— X11 轉送的客戶端選項,包括不受信任和受信任之間的差異-Y。將按需作業運行替換為 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 在規定的保留期後刪除已刪除的文件,可靠地安排後台作業,並避免執行清除所有使用者回收站的命令。