An ownCloud upload that reaches 99 percent and then appears to freeze is usually not solved by repeatedly starting the upload again. At that point, the browser may have already transferred most or all of the file while the server is still completing work such as receiving the last chunk, assembling chunks, moving the completed file into its destination, updating metadata, or releasing locks. The percentage alone does not identify the cause, so the fastest approach is to check the server-side evidence in a fixed order.
This guide uses the current ownCloud Server 11.0 administration documentation available in October 2026. The same ideas apply to many ownCloud Classic deployments, but configuration paths and Docker behavior can differ on older releases. Before changing limits, confirm your installed version and deployment method.
| What to check | Why it matters | Strong clue |
|---|---|---|
| ownCloud, PHP, and web-server logs | The failure may occur after the browser finishes sending data. | Timeout, storage, WebDAV, locking, 5xx, or permission error at the upload time. |
| Temporary and upload-directory free space | Chunked uploads need temporary storage before finalization. | Large files fail while small files work, or the filesystem is nearly full. |
| User quota and destination storage | The final file still needs room in its destination. | Failure happens only for one user, folder, or external-storage target. |
| PHP upload and time limits | Non-chunked requests and supporting requests can be rejected or time out. | Errors mention request size, execution time, input time, or temporary upload files. |
| Session lifetime | A session that expires before a long upload finishes can interrupt completion. | Failures correlate with upload duration rather than file type. |
| Reverse proxy, CDN, or load balancer | An upstream component can impose its own body-size or timeout limit. | Direct access works but the public hostname through the proxy fails. |
| Transactional file locking | ownCloud locks files while file operations are committed. | Logs contain locking errors, especially under load or on clustered storage. |
Do one controlled upload with a file that reliably reproduces the problem and note the exact time. Then inspect the ownCloud log, PHP log, and web-server error log around that timestamp. Do not make several configuration changes first; doing so makes it harder to know which layer actually failed.
Oficjalna dokumentacja rozwiązywania problemów ownCloud wyraźnie zaleca sprawdzenie logów PHP, Apache i ownCloud w pierwszej kolejności. W standardowym wdrożeniu Dockera, ownCloud dokumentuje, że dane wyjściowe Apache i PHP są kierowane przez stdout/stderr kontenera i sugeruje śledzenie logów kontenera za pomocą docker compose logs owncloud -f.
Dziennik ownCloud można również uzyskać z interfejsu administratora. Przewodnik po dzienniku i konfiguracji ownCloud opisuje ścieżkę przez Ustawienia > Administracja > Ogólne i zawiera informację, occ configreport:generatekiedy potrzebny jest pełniejszy raport konfiguracji.
Skoncentruj się na pierwszym błędzie związanym z nieudanym żądaniem, a nie na każdym ostrzeżeniu, które po nim następuje. Przydatne kategorie obejmują przekroczenie limitu czasu żądania, niewystarczającą ilość miejsca na dane, brak możliwości utworzenia lub zmiany nazwy pliku tymczasowego, błędy uprawnień, wyjątki WebDAV, odpowiedzi HTTP 413/502/504 oraz błędy blokowania plików. Jeśli tymczasowo zmienisz poziom logowania w ownCloud na DEBUG, przywróć go później do normalnego poziomu; ownCloud zaznacza, że szczegółowe logowanie może wpływać na wydajność serwera. Zobacz oficjalne informacje dotyczące konfiguracji logowania .
To jedna z najważniejszych kontroli w przypadku 99-procentowego opóźnienia. Serwer ownCloud 11.0 wyjaśnia, że przesyłanie danych może wykorzystywać więcej niż jeden obszar tymczasowy. Tymczasowy katalog przesyłania danych PHP musi mieć miejsce na aktywne fragmenty, podczas gdy katalog przesyłania danych użytkownika gromadzi fragmenty pliku do momentu zakończenia przesyłania.
Zgodnie z dokumentacją ownCloud dotyczącą przesyłania dużych plików , tymczasowa przestrzeń PHP powinna być rozplanowana mniej więcej jako liczba jednoczesnych przesłań pomnożona przez rozmiar fragmentu. Co ważniejsze, w przypadku dużego pojedynczego pliku, katalog przesyłania użytkownika tymczasowo potrzebuje przestrzeni porównywalnej z rozmiarem pliku końcowego, ponieważ przechowuje fragmenty do momentu zakończenia asemblacji. Po zakończeniu przesyłania ownCloud zapisuje fragmenty w miejscu docelowym i usuwa je.
Sprawdź system plików zawierający katalog danych, katalog tymczasowy PHP i dowolną lokalizację skonfigurowaną za pomocą [brakuje kontekstu] OWNCLOUD_DAV_CHUNK_BASE_DIR. Sprawdź również faktyczne miejsce docelowe, zwłaszcza gdy jest to pamięć zewnętrzna. Serwer może mieć dużo wolnego miejsca, /podczas gdy oddzielny wolumin danych jest pełny.
Nie przenoś ręcznie plików do ani z katalogu danych ownCloud, aby „dokończyć” przesyłanie. ownCloud ostrzega, że jego katalog danych jest przeznaczony wyłącznie dla aplikacji; bezpośrednie modyfikacje mogą powodować niespójności synchronizacji i bazy danych.
Limit użytkownika może zablokować duży plik końcowy, nawet jeśli obszar roboczy przesyłania ma wystarczająco dużo miejsca. Sprawdź limit użytkownika, którego to dotyczy, oraz, jeśli to konieczne, pojemność i uprawnienia do zamontowania zewnętrznego urządzenia pamięci masowej. Przydatnym testem jest przesłanie tego samego pliku na inne konto lub do innego miejsca docelowego z wystarczającą ilością miejsca. Jeśli błąd dotyczy użytkownika lub folderu, a nie pliku, limit lub polityka pamięci masowej przesuwają się wyżej na liście.
Jeśli logi wskazują na rozmiar żądania lub limity wykonania, sprawdź aktualne ustawienia PHP, zamiast zakładać, że wartości w losowym php.inipliku są aktywne. Typowe dyrektywy to post_max_size, upload_max_filesize, upload_tmp_dir, max_input_time, max_execution_timei memory_limit.
W przypadku obsługiwanej konfiguracji serwera ownCloud Server 11.0 w środowisku Dockerized dokumentacja mapuje je na zmienne środowiskowe: OWNCLOUD_MAX_UPLOAD, OWNCLOUD_TEMP_DIRECTORY, OWNCLOUD_MAX_INPUT_TIME, OWNCLOUD_MAX_EXECUTION_TIMEi OWNCLOUD_MEMORY_LIMIT. Jest to istotne, ponieważ ownCloud deklaruje, że wdrożenia korzystające z konfiguracji Docker powinny korzystać z udostępnionych zmiennych środowiskowych, zamiast polegać na starszym PHP lub .htaccesswzorcach dostosowywania.
Nie ustawiaj po prostu każdego limitu na skrajnie wysoką liczbę. Lepszym celem jest wartość, która uwzględnia maksymalny rozmiar pliku i najwolniejsze dozwolone połączenie, a jednocześnie zachowuje bezpieczeństwo operacyjne.
OwnCloud wyraźnie ostrzega, że czas session_lifetimeprzesyłania nie może być krótszy niż najdłuższy oczekiwany czas przesyłania. Jeśli go zmodyfikowałeś, ustaw go co najmniej na liczbę sekund wymaganą przez najwolniejszy oczekiwany czas przesyłania lub usuń zbędną wartość niestandardową i przywróć domyślne ustawienie.
Warto to sprawdzić szczególnie wtedy, gdy plik o rozmiarze 500 MB kończy się pomyślnie, ale plik o rozmiarze wielu gigabajtów wielokrotnie kończy się niepowodzeniem po upływie mniej więcej takiego samego czasu.
W obszernej dokumentacji ownCloud zaznaczono, że serwery proxy po stronie klienta i usługi takie jak Cloudflare mogą ograniczać przesyłanie danych. Oznacza to, że nawet idealnie skonfigurowany stos ownCloud/PHP może ulec awarii, ponieważ kolejny przeskok ograniczy treść żądania, buforuje długie żądanie, zamyka bezczynne połączenie lub przekracza limit czasu, podczas gdy ownCloud agreguje przesyłanie danych.
Jeśli Twoja architektura umożliwia bezpieczny test administracyjny, porównaj to samo przesyłanie przez standardową trasę publiczną i przez ścieżkę omijającą odwrotny serwer proxy lub CDN. Jeśli ścieżka bezpośrednia zakończy się powodzeniem, sprawdź oficjalną dokumentację tego pośrednika pod kątem rozmiaru żądania, limitu czasu przesyłania, buforowania i działania WebDAV. Nie osłabiaj protokołu TLS ani nie udostępniaj publicznie zaplecza tylko po to, aby wykonać ten test.
Blokowanie plików transakcyjnych jest domyślnie włączone i chroni pliki przed jednoczesną mutacją. Dokumenty ownCloud wskazują, że ma to również znaczenie podczas składania przesyłanych fragmentów. Na obciążonych serwerach problem z blokowaniem może wyglądać jak transfer, który został zakończony, ale nie mógł zostać poprawnie zatwierdzony.
Przed zmianą tego podsystemu należy zapoznać się z dokumentacją dotyczącą blokowania plików transakcyjnych . Firma ownCloud zaleca korzystanie z zaplecza pamięci podręcznej do blokowania przy większych obciążeniach, zamiast polegać na blokowaniu bazy danych. W przypadku wdrożeń klastrowych, współdzielone blokowanie Redis jest szczególnie ważne, ponieważ każdy węzeł aplikacji musi widzieć ten sam stan blokady.
Istnieje również udokumentowany przypadek szczególny dla bardzo długich przesyłów do folderów publicznych, gdy dzielenie na fragmenty nie jest włączone. Własna chmura informuje, że przesyłanie trwające dłużej niż godzinę może wymagać odpowiednio dużego pliku OWNCLOUD_FILELOCKING_TTL; w przeciwnym razie odśmiecanie pamięci Redis może usunąć blokadę nałożoną na początku operacji. Nie zmieniaj tego ustawienia, chyba że ścieżka przesyłania jest zgodna z tym scenariuszem.
Po rozwiązaniu jednego zidentyfikowanego problemu spróbuj ponownie z tym samym plikiem, kontem, miejscem docelowym, przeglądarką i ścieżką sieciową. Następnie sprawdź trzy rzeczy: czy proces dobiegł końca, czy plik pojawia się w miejscu docelowym o oczekiwanym rozmiarze, a logi nie zawierają nowego błędu dla tego żądania.
Przydatną sekwencją jest mały plik, średni plik i wreszcie rozmiar pliku, który pierwotnie nie został przetworzony. Jeśli małe pliki zawsze kończą się powodzeniem, ale awarie zaczynają się powyżej powtarzalnego rozmiaru, skoncentruj się na pojemności pamięci masowej i limitach rozmiaru. Jeśli awarie zaczynają się po powtarzalnym czasie, skoncentruj się na sesjach i limitach czasu. Jeśli występują tylko przez jedną nazwę hosta lub ścieżkę sieciową, skoncentruj się na serwerach proxy i modułach równoważenia obciążenia.
Jeśli potrzebujesz krótkiego podręcznika, zastosuj następującą kolejność: odtwórz raz; odczytaj logi ownCloud/PHP/serwera WWW; sprawdź dane, pamięć tymczasową i pamięć podręczną; zweryfikuj limit; potwierdź efektywne ustawienia przesyłania i czasu; sprawdź czas życia sesji; omiń lub sprawdź odwrotny serwer proxy/CDN; a następnie sprawdź blokady transakcyjne. Ta kolejność faworyzuje dowody i ograniczenia infrastruktury o najwyższym prawdopodobieństwie przed ryzykownymi zmianami konfiguracji.
Ważne jest, że „99 procent” samo w sobie nie jest kodem błędu. Wskazuje, gdzie użytkownik zauważył problem, a nie który komponent go spowodował. Niezawodne rozwiązanie polega na dopasowaniu znacznika czasu nieudanego przesłania do pamięci masowej, przekroczenia limitu czasu, serwera proxy, sesji lub zablokowania dowodów na serwerze.
Porównaj 10 narzędzi do pingowania, które umożliwiają szybkie wykrywanie sieci LAN, skanowanie międzyplatformowe i zarządzanie adresami IP. Dowiedz się, co narzędzie pingujące może Ci powiedzieć, a czego nie.
Porównaj sześć narzędzi do zarządzania siecią służących do monitorowania wydajności, obejmujących zasięg SNMP, mapowanie, alerty, modele wdrażania i kompromisy kosztów.
Porównaj siedem darmowych i otwartych monitorów pingów — od kompletnych pakietów sieciowych po ukierunkowane sondy opóźnień — i wybierz odpowiedni monitor pod kątem dostępności, utraty pakietów i historii.
Dowiedz się, co oznacza QoS w sieciach, w jaki sposób oznaczenia DSCP i kolejki ruchu nadają priorytet aplikacjom głosowym, wideo i biznesowym oraz czego QoS nie jest w stanie naprawić.
Porównaj niezawodne oprogramowanie serwera SFTP dla systemów Windows i Linux, w tym OpenSSH, Bitvise, SolarWinds i SFTPGo. Znajdź rozwiązanie odpowiednie dla swoich potrzeb w zakresie bezpieczeństwa i transferu plików.
Porównaj siedem narzędzi do zarządzania adresami IP służących do wykrywania podsieci, koordynacji DNS i DHCP, inwentaryzacji sieci i otwartego oprogramowania IPAM.
Porównaj sześć narzędzi do monitorowania systemu Windows Server pod kątem zbierania danych systemu Windows, widoczności aplikacji, modelu wdrażania i licencjonowania, aby znaleźć odpowiednie rozwiązanie.
Porównaj narzędzia do skanowania sieciowego umożliwiające szybkie wykrywanie urządzeń, skanowanie adresów IP na wielu platformach oraz zarządzanie IPAM w przedsiębiorstwie. Znajdziesz tu wskazówki dotyczące dopasowania każdej opcji do swojej sieci.
Zbuduj praktyczny monitoring sieci z przejrzystym zakresem urządzeń, przydatnymi wskaźnikami wydajności, przydatnymi alertami oraz porównaniem SolarWinds NPM, PRTG i OpManager.
Użyj opcji --traceroute programu Nmap, aby mapować przeskoki do autoryzowanego hosta, zrozumieć dane wyjściowe dotyczące przeskoków i czasu RTT oraz rozwiązywać problemy z brakującymi odpowiedziami bez nadmiernego skanowania.
