Gdy strona plików ownCloud osiągnie 99%, przed ponowną próbą sprawdź najpierw, czy cały plik znajduje się już w folderze docelowym. Jeśli brakuje pliku lub jest on niekompletny, poproś administratora o sprawdzenie limitu użytkownika, wolnego miejsca w katalogach tymczasowych PHP i fragmentów ownCloud, a następnie limitów żądań PHP i serwera WWW. Wskaźnik 99% nie wystarczy, aby zidentyfikować, która część uległa awarii.
Ten praktyczny przewodnik obejmuje przesyłanie danych za pośrednictwem interfejsu internetowego serwera ownCloud (Classic) 10.16. Przesyłanie danych w trybie Infinite Scale i synchronizacja z pulpitem korzystają z różnych ścieżek serwera i logów. Przykłady pochodzą z oficjalnej dokumentacji 10.16; użyj ustawień i ścieżek plików we własnym wdrożeniu.
| Co widzisz | Sprawdź najpierw |
|---|---|
| Po odświeżeniu folderu plik wydaje się kompletny | Porównaj jego rozmiar z plikiem lokalnym i otwórz go przed ponownym przesłaniem. |
| Tylko duże pliki się zawieszają lub nie działają | Porównaj rozmiar pliku z ograniczeniami PHP, serwera WWW i serwera proxy; sprawdź pamięć tymczasową. |
| Przesyłanie nie powiodło się dla jednego użytkownika lub jednego folderu | Sprawdź limit miejsca dla danego użytkownika, uprawnienia do folderów i czy miejsce docelowe znajduje się w pamięci zewnętrznej. |
| Przesyłanie plików kończy się niepowodzeniem u wielu użytkowników | Sprawdź współdzieloną przestrzeń dyskową, logi PHP/serwera WWW oraz wszelkie limity serwera proxy lub hostingu. |
Otwórz folder docelowy w drugiej karcie lub odśwież go po zakończeniu przesyłania. Jeśli plik jest obecny, porównaj jego rozmiar w bajtach z lokalnym oryginałem i otwórz go. Kompletny plik z nieaktualnym paskiem postępu wskazuje na brak odpowiedzi na żądanie ukończenia lub problem z wyświetlaniem w przeglądarce; nie uzasadnia to przesyłania drugiej kopii.
Jeśli plik jest nieobecny lub ma mniejszy rozmiar, wypróbuj mały plik testowy w tym samym folderze, a następnie spróbuj pobrać oryginał z innej przeglądarki lub sieci, jeśli jest dostępny. Zapisz rozmiar pliku, użytkownika, miejsce docelowe, przybliżony czas oraz informację, czy test zakończył się niepowodzeniem. Takie porównania pomagają odróżnić problem z pojedynczym plikiem lub klientem od problemu obejmującego cały serwer. Unikaj wielokrotnego anulowania i ponownego uruchamiania dużego przesyłania, gdy serwer nadal je przetwarza.
Poproś administratora ownCloud o sprawdzenie limitu danych danego użytkownika oraz uprawnień zapisu w folderze docelowym. Limit może uniemożliwić zapisanie nowego pliku, nawet gdy przeglądarka przesłała już większość danych. Jeśli miejscem docelowym jest zewnętrzny serwer montowany, sprawdź również dostępną przestrzeń i uprawnienia zapisu w tym serwerze.
Na serwerze sprawdź wolne bloki i inody w katalogu danych i każdym odpowiednim katalogu tymczasowym. Inod to rekord systemu plików używany do tworzenia pliku; wolumin może mieć wolne gigabajty, ale nie może mieć żadnych inodów. Użyj rzeczywistych ścieżek z konfiguracji PHP i ownCloud:
df -h /path/to/owncloud-data /path/to/php-temp /path/to/chunk-temp
df -i /path/to/owncloud-data /path/to/php-temp /path/to/chunk-tempPliki PHP upload_tmp_dirmuszą mieć uprawnienia do zapisu z poziomu konta PHP/serwera WWW. Własna chmura ma również ustawienia katalogu tymczasowego, a przesyłane fragmenty są domyślnie umieszczane w katalogu uploads użytkownika. Podczas kompilacji, własna chmura może potrzebować tymczasowej przestrzeni mniej więcej równej rozmiarowi pliku końcowego. Użytkownik dav.chunk_base_dirmoże zmienić tę lokalizację. Sprawdź wszystkie te woluminy, a nie tylko główny dysk danych.
Jeśli małe pliki działają, a większy nie, porównaj jego rozmiar z efektywnymi ustawieniami web-PHP: upload_max_filesizei post_max_size. PHP wymaga post_max_sizerozmiaru większego niż upload_max_filesize. Sprawdź konfigurację PHP używaną przez serwer webowy lub PHP-FPM; konfiguracja PHP w wierszu poleceń może być inna. W konfiguracjach PHP-FPM, ownCloud zaznacza, że ustawienia PHP powinny znajdować się w .user.inikonfiguracji FPM, a nie tylko w .htaccess.
Sprawdź również, max_input_timekiedy przesyłanie trwa długo i czy w logach jest widoczny limit czasu wykonania PHP, jeśli log go wskazuje. Ustaw limity dla oczekiwanego obciążenia zamiast kopiować przykładową liczbę; po zmianie konfiguracji zrestartuj lub przeładuj PHP i serwer WWW. Zobacz konfigurację przesyłania dużych plików w ownCloud i referencje dotyczące dyrektyw przesyłania w PHP .
Następnie sprawdź każdą warstwę HTTP przed PHP. Nginx client_max_body_sizeodrzuca zbyt duże ciała żądań z błędem HTTP 413; ustaw go wystarczająco wysoko, aby dopasować go do rozmiaru żądania używanego przez ścieżkę przesyłania. Apache LimitRequestBodyi mod_reqtimeoutmogą również ograniczać przesyłanie. ownCloud ostrzega, że odwrotne proxy, Cloudflare, limity wejścia/wyjścia hostingu i ustawienia limitu czasu żądania Apache mogą wpływać na duże przesyłanie. Zmień tylko warstwę, której dotyczą logi, i unikaj globalnego wyłączania modułów bezpieczeństwa jako pierwszego rozwiązania. Zapoznaj się z oficjalną dokumentacją Nginx dotyczącą ciał żądań .
Powtórz problem raz, notując godzinę, a następnie sprawdź dziennik ownCloud oraz dziennik błędów serwera WWW lub serwera proxy z tej samej minuty. Dziennik ownCloud zazwyczaj znajduje się w skonfigurowanym katalogu danych; rzeczywistą ścieżkę można zmienić w config.php. Wyszukaj komunikaty dotyczące limitu, uprawnień, plików tymczasowych, blokad, rozmiaru żądania lub przekroczenia limitu czasu. Jeśli żądanie nigdy nie pojawia się w dzienniku ownCloud, najpierw sprawdź serwer proxy lub serwer WWW.
tail -n 100 /path/to/owncloud.logZastąp symbol zastępczy ścieżką skonfigurowaną w instalacji. Polecenie wyświetla tylko ostatnie wiersze logu; nie zmienia danych serwera. Unikaj publicznego publikowania surowych logów bez usuwania nazw użytkowników, ścieżek plików, adresów IP i tokenów. OwnCloud wyjaśnia lokalizacje logów w dokumentacji debugowania .
Nie zwiększaj wszystkich limitów ani nie wyłączaj zabezpieczeń żądań jednocześnie. Celowa zmiana, po której nastąpi jedna kontrolowana ponowna próba, ułatwia potwierdzenie przyczyny i zachowuje pozostałą konfigurację serwera bez zmian.
Przywróć synchronizację pulpitu ownCloud, sprawdzając nazwę hosta serwera, łańcuch certyfikatów, zaufanie prywatnego urzędu certyfikacji i problemy z portalem uwierzytelniającym bez wyłączania weryfikacji TLS.
Użyj raportu o nieprawidłowych plikach, aby zidentyfikować niezgodne pliki główne lub podpisy aplikacji, przywrócić prawidłowe pliki wydania i bezpiecznie zweryfikować kontrolę integralności.
Wdróż ownCloud Infinite Scale z oficjalnego przykładu Compose, skonfiguruj domeny i trwałą pamięć masową, a następnie zweryfikuj protokół TLS, kontenery i pierwsze logowanie.
Skonfiguruj sterownik S3NG, uprawnienia kontenera, trwałe przechowywanie metadanych i rozmiar przesyłanych danych, aby ownCloud Infinite Scale mógł niezawodnie przechowywać zawartość plików.
Dowiedz się, dlaczego przesyłanie danych na serwer ownCloud zatrzymuje się przed ukończeniem, sprawdzając status pliku, limit, tymczasową przestrzeń na dysku, limity PHP i limity czasu serwera proxy.
Ustaw opcję AllowOverride All tylko dla głównego katalogu internetowego ownCloud, sprawdź aktywny vhost Apache i bezpiecznie przeładuj, aby przywrócić reguły .htaccess.
Włącz aplikację Enterprise Auditing firmy ownCloud, kieruj zdarzenia admin_audit do chronionego pliku dziennika i upewnij się, że rejestrowane są rzeczywiste działania użytkowników.
Wydawca domeny, klient sieciowy i użytkownik Keycloak są zgodne z oświadczeniami, dzięki którym ownCloud Infinite Scale może niezawodnie logować użytkowników za pośrednictwem klientów sieciowych i mobilnych.
Przenieś swoje pliki i udziały wychodzące za pomocą polecenia occ usługi ownCloud, sprawdź, co pozostaje, i zweryfikuj dostęp przed usunięciem starego konta.
Dowiedz się, kiedy indeksy bazy danych ownCloud 10 wymagają uwagi, jak bezpiecznie stosować obsługiwane aktualizacje schematu oraz kiedy lepszym rozwiązaniem jest dostrojenie zapytań lub zmiana bazy danych.
