解決 ownCloud 檔案上傳卡在 99% 的問題：實用故障排除指南

ownCloud 檔案上傳到 99% 後似乎卡住，通常無法透過重複重啟上傳來解決。此時，瀏覽器可能已經傳輸了大部分甚至全部文件，而伺服器仍在完成一些工作，例如接收最後一個資料區塊、組裝資料區塊、將完成的文件移動到目標位置、更新元資料或釋放鎖定。僅憑上傳進度百分比無法確定問題原因，因此最快的方法是以固定順序檢查伺服器端的各項操作。

本指南使用 2026 年 10 月發布的 ownCloud Server 11.0 最新管理文件。雖然其中的一些想法也適用於許多 ownCloud Classic 部署，但舊版本在配置路徑和 Docker 行為方面可能有所不同。在變更限制之前，請確認您已安裝的版本和部署方式。

ownCloud 檔案視圖顯示，一個大檔案上傳在 99% 時停止。 — 即使大部分資料已經傳輸完畢，檔案傳輸進度也可能顯示停留在 99%。請將此進度百分比視為一個徵兆，然後檢查伺服器端是否有異常。

快速診斷清單

需要檢查什麼	為什麼這很重要	重要線索
ownCloud、PHP 和 Web 伺服器日誌	故障可能發生在瀏覽器完成資料發送之後。	上傳時出現逾時、儲存、WebDAV、鎖定、5xx 錯誤或權限錯誤。
暫存目錄和上傳目錄的可用空間	分塊上傳需要在最終處理前進行暫時儲存。	大檔案傳輸失敗，而小檔案傳輸正常，或檔案系統幾乎已滿。
用戶配額和目標存儲	最終檔案在目標位置仍需留出空間。	故障僅發生在單一使用者、資料夾或外部儲存目標上。
PHP 上傳和時間限制	非分塊請求和輔助請求可能會被拒絕或逾時。	錯誤訊息會提及請求大小、執行時間、輸入時間或暫時上傳檔案。
會話生命週期	長時間上傳完成前會話過期可能會中斷上傳過程。	上傳失敗與上傳時長相關，而非文件類型。
反向代理、CDN 或負載平衡器	上游元件可以自行設定主體大小或逾時限制。	直接存取可以，但透過代理存取公共主機名稱失敗。
交易文件鎖定	ownCloud 會在檔案操作提交期間鎖定檔案。	日誌中包含鎖定錯誤，尤其是在負載較高或叢集儲存的情況下。

1. 重現問題一次，然後立即檢查日誌。

使用一個能夠穩定重現問題的檔案進行一次受控上傳，並記下確切時間。然後檢查該時間戳附近的 ownCloud 日誌、PHP 日誌和 Web 伺服器錯誤日誌。不要事先進行多項配置變更；這樣做會使確定實際出錯的層級變得更加困難。

ownCloud 的官方故障排除文件明確建議先檢查 PHP、Apache 和 ownCloud 日誌。在標準的 Docker 部署中，ownCloud 文件指出 Apache 和 PHP 的輸出會透過容器的 stdout/stderr 進行路由，並建議使用以下命令追蹤容器日誌docker compose logs owncloud -f。

ownCloud 管理頁面，包含日誌記錄控制項和「下載日誌檔案」按鈕 — 在變更上傳限制之前，管理日誌檢視是收集證據的地方之一。

您也可以透過管理介面來取得 ownCloud 日誌。 ownCloud日誌和設定指南詳細介紹了「設定」>「管理」>「常規」的步驟，並occ configreport:generate在需要更完整的設定報告時提供了相應的選項。

應該查看哪些日誌資訊？

重點關注與失敗請求相關的第一個錯誤，而不是其後出現的所有警告。有用的錯誤類別包括請求逾時、儲存空間不足、無法建立或重新命名暫存檔案、權限錯誤、WebDAV 異常、HTTP 413/502/504 回應以及檔案鎖定失敗。如果您暫時將 ownCloud 日誌等級提升至 DEBUG，請之後將其還原為正常等級；ownCloud 指出，詳細的日誌記錄可能會影響伺服器效能。請參閱官方日誌配置參考。

終端風格的視圖，展示了上傳失敗期間 ownCloud 的日誌條目 — 請讀取上傳失敗時確切時間點的日誌條目。此處顯示的資訊僅供參考；請根據您伺服器的實際日誌進行診斷。

2. 檢查臨時存放地點和最終存放地點的可用空間

這是導致上傳進度停滯（99%）的最重要檢查之一。 ownCloud Server 11.0 說明上傳作業可以使用多個臨時區域。 PHP 上傳暫存目錄必須有足夠的空間來存放活動的資料區塊，而使用者上傳目錄則會收集檔案的資料區塊，直到上傳完成。

根據ownCloud 大文件上傳文檔，臨時 PHP 空間應大致規劃為並發上傳數量乘以資料塊大小。更重要的是，對於大型單一文件，使用者的上傳目錄需要暫時佔用與最終文件大小相當的空間，因為它用於存放資料區塊，直到文件合併完成。上傳完成後，ownCloud 會將資料塊寫入最終目標位置並刪除目錄。

終端機顯示 ownCloud 資料和臨時目錄的磁碟可用空間檢查結果 — 檢查包含 ownCloud 資料目錄、PHP 暫存目錄和任何專用資料區塊上傳目錄的檔案系統上的可用空間。

檢查包含資料目錄、PHP 暫存目錄以及透過設定檔配置的任何位置的檔案系統OWNCLOUD_DAV_CHUNK_BASE_DIR。同時，驗證實際目標位置，尤其是在目標是外部儲存時。伺服器的檔案系統可能有很多可用空間，/但單獨的資料卷可能已滿。

請勿手動將檔案移入或移出 ownCloud 資料目錄以「完成」上傳。 ownCloud 警告稱，其資料目錄僅供該應用程式使用；直接修改可能會導致同步和資料庫不一致。

3. 提高技術限制前，請確認配額

使用者配額可能會阻止上傳大型最終文件，即使上傳暫存區空間充足。請檢查受影響使用者的配額，以及（如果相關）外部儲存掛載點的容量和權限。一個有效的測試方法是將相同文件上傳到另一個空間充足的帳戶或目標位置。如果上傳失敗的原因是使用者或資料夾而非檔案本身，則表示配額或儲存策略有問題。

4. 檢查 PHP 和 ownCloud 上傳設置

如果日誌指向請求大小或執行限制，請檢查實際的 PHP 設置，而不是假設隨機php.ini檔案中的值是有效的。常用指示包括post_max_size`--size`、upload_max_filesize` --command`、`--command` 、`--command`、upload_tmp_dir` --command` 和 `--command` 。max_input_timemax_execution_timememory_limit

配置編輯器展示了 PHP 上傳大小、輸入時間、執行時間和記憶體設定。 — 只有當日誌或有效配置顯示 PHP 限制正在限制上傳時，才應變更 PHP 限制。此處顯示的數值僅供參考，並非一般建議。

對於受支援的 Docker 化 ownCloud Server 11.0 配置，文件中將這些參數對應到下列環境變數：OWNCLOUD_MAX_UPLOAD、、、、和。這一點很重要，因為 ownCloud 指出，使用其 Docker 配置的部署應該使用提供的環境變量OWNCLOUD_TEMP_DIRECTORY，而不是依賴舊的 PHP 或自訂模式。OWNCLOUD_MAX_INPUT_TIMEOWNCLOUD_MAX_EXECUTION_TIMEOWNCLOUD_MEMORY_LIMIT.htaccess

編輯器顯示了包含上傳相關環境變數的 ownCloud Docker Compose 服務。 — 在 Docker 部署中，請將上傳相關設定保存在受支援的環境變數配置中，並驗證掛載的暫存是否有足夠的容量。所示數值僅供參考。

不要簡單地將所有限制值都設定得太大。更合適的數值應該是既能滿足您預期最大文件大小的要求，又能適應最慢的合法連線速度，同時還能保障運作安全。

5. 檢查會話持續時間以查找慢上傳原因

ownCloud 特別提醒，上傳時間session_lifetime不得短於最長的預期上傳時間。如果您已自訂此值，請將其設定為至少最慢的預期上傳時間所需的秒數，或刪除不必要的自訂值並恢復到受支援的預設行為。

當一個 500 MB 的檔案下載完成，而一個幾 GB 的檔案在大致相同的經過時間後反覆下載失敗時，這一點尤其值得檢查。

6. 分別測試反向代理或 CDN

ownCloud 的大文件上傳文件指出，客戶端代理程式和服務（例如 Cloudflare）可能會限制上傳。這意味著即使配置完美，ownCloud/PHP 協定堆疊仍然可能失敗，原因可能是其他環節限制了請求體、緩衝了過長的請求、關閉了空閒連接，或者 ownCloud 在組裝上傳檔案時逾時。

如果您的架構允許進行安全的管理測試，請比較透過正常公共路由和繞過反向代理或 CDN 的路徑上傳的相同檔案。如果直接路徑成功，請檢查該中間服務的官方文檔，以了解請求大小、上傳逾時、緩衝和 WebDAV 行為。請勿為了執行此測試而降低 TLS 安全性或公開後端。

伺服器設定編輯器，展示了大型上傳檔案的 Web 伺服器逾時設置 — 反向代理或 Web 伺服器可以自行設定逾時時間。這僅作為提醒，提醒您檢查該層；指令名稱和安全性值取決於您的實際伺服器堆疊。

7. 檢查上傳失敗時檔案鎖定情況（在最終確定過程中）。

事務性檔案鎖定預設啟用，可防止檔案同時被修改。 ownCloud 文件指出，在分塊上傳時，事務性文件鎖定也至關重要。在繁忙的伺服器上，鎖定問題可能表現為傳輸已完成但無法正常提交。

在變更此子系統之前，請查閱事務性文件鎖定文件。 ownCloud 建議在處理高負載工作負載時使用記憶體快取後端進行鎖定，而不是依賴資料庫鎖定。在叢集部署中，共用 Redis 鎖定尤為重要，因為每個應用程式節點都必須看到相同的鎖定狀態。

對於長時間上傳到公共資料夾且未啟用分塊上傳的特殊情況，ownCloud 文件中也記錄了相關資訊。 ownCloud 指出，超過一小時的上傳可能需要足夠大的記憶體OWNCLOUD_FILELOCKING_TTL；否則，Redis 垃圾回收機制可能會移除操作開始時所取得的鎖定。除非您的上傳路徑符合這種情況，否則請勿變更此設定。

8. 每次更改後都要進行系統性的重新測試。

ownCloud 上傳面板顯示一個大型 ZIP 文件，上傳進度已達 99%。 — 每次伺服器端更改後，重複一個已知的測試檔案並記錄結果，而不是一次更改多個層。

解決已發現的問題後，請使用相同的檔案、帳戶、目標位置、瀏覽器和網路路徑重試。然後驗證三件事：進度條是否完成、檔案是否以預期大小出現在目標位置，以及日誌中是否包含該要求的新錯誤。

一個有效的檢查方法是：先嘗試小文件，再嘗試中等大小的文件，最後嘗試最初導致失敗的文件大小。如果小檔案總是能成功傳輸，但失敗是從超過某個可重複出現的檔案大小開始的，則應重點檢查儲存容量和檔案大小限制。如果失敗是在一段可重複出現的時間段後發生的，則應重點檢查會話和逾時問題。如果失敗僅發生在特定的主機名稱或網路路徑上，則應專注於檢查代理程式和負載平衡器。

不該做什麼

不要在未查看日誌的情況下反覆嘗試上傳數GB的檔案。重複上傳失敗會消耗時間，並可能暫時佔用儲存空間。
請勿手動修改 ownCloud 資料目錄。請使用 ownCloud、WebDAV 或支援的管理工具。
請勿將停用檔案鎖定作為首要修復方案。鎖定機制可以保護資料完整性；請先診斷後端問題。
不要因為某個 PHP 設定出現在一個設定檔中就認為它有效。容器、PHP-FPM、Apache 模組以及多個 INI 檔案位置都可能導致不同的有效設定。
不要無限期地提高超時時間。找到導致請求關閉的層，並設定一個與最大支援上傳量相符的限制。

實際決策路徑

如果需要一份簡潔的操作指南，請按以下順序操作：重現一次問題；讀取 ownCloud/PHP/Web 伺服器日誌；檢查資料、臨時和分塊儲存；驗證配額；確認有效的上傳和時間設定；檢查會話生命週期；繞過或檢查反向代理/CDN；然後調查事務鎖定問題。此順序優先考慮證據和可能性最高的底層架構限制，然後再進行風險較高的配置變更。

關鍵在於，「99%」本身並不是錯誤代碼。它表示使用者發現問題的位置，而不是導致問題的元件。可靠的解決方法是將上傳失敗的時間戳與伺服器上儲存、逾時、代理、會話或鎖定等證據進行配對。