Gdy w aplikacji Pliki ZimaOS wyświetla się komunikat Błąd ładowania, ale dostęp SMB z systemu Windows nadal działa, nie zakładaj od razu, że macierz RAID lub dane zniknęły. Taki schemat wystąpił w wątku z lutego 2026 roku: interfejs Plików przestał działać po aktualizacji do wersji 1.5.4, podczas gdy inne aplikacje i dostęp do plików przez Sambę nadal działały.
Pracownicy IceWhale później wskazali najważniejszą granicę przyczyny problemu. raller1028 powiedział, że w ZimaOS 1.5.4, gdy dysk systemowy jest pełny, usługa Plików może przestać działać prawidłowo. Oficjalne rozwiązanie polegało na zwolnieniu miejsca na dysku systemowym i ponownym uruchomieniu usługi icewhale-files. Osobne społecznościowe obejście polegające na zmianie nazwy bazy danych pomogło kilku użytkownikom, ale IceWhale nie przedstawiał go jako rozwiązania pierwszego wyboru.
Działający SMB to mocny dowód, że dane i punkty montowania nadal istnieją
Autor oryginalnego wpisu nadal mógł uzyskiwać dostęp do plików przez udział Samby w systemie Windows. Oznacza to, że pamięć masowa hosta i ścieżka dostępu do danych działały, mimo że aplikacja webowa Plików nie mogła ich wyświetlić.
To ważne rozróżnienie między:
- utratą danych lub pamięci masowej;
- awarią usługi Plików;
- awarią przeglądarki lub interfejsu.
Pliki nie są zwykłym kontenerem Docker ze sklepu aplikacji
Dlatego brak kontenera Plików w wyniku docker ps jest spodziewany. Ponowne uruchamianie przypadkowych kontenerów Docker nie naprawi natywnej usługi Plików.
IceWhale wskazał pełny dysk systemowy jako przyczynę problemu w wersji 1.5.4
26 lutego raller1028 z IceWhale napisał, że problem „powinien” być spowodowany pełnym dyskiem systemowym w wersji 1.5.4.
Oficjalna procedura odzyskiwania obejmowała:
- zwolnienie miejsca na dysku systemowym za pomocą wiersza poleceń;
- ponowne uruchomienie usługi Plików:
systemctl restart icewhale-filesUżytkownikom nieznającym się na czyszczeniu systemu z poziomu wiersza poleceń zalecono skontaktowanie się z pomocą techniczną zamiast bezmyślnego usuwania plików.
Dlaczego pełny dysk systemowy może wyłączyć Pliki, gdy SMB nadal działa
Natywne usługi potrzebują wolnego miejsca na bazy danych, stan aplikacji, pliki tymczasowe, logi i operacje serwisowe. Duże dane użytkownika mogą pozostać nienaruszone na innej macierzy, podczas gdy mała partycja systemowa osiągnie 100% wykorzystania i spowoduje awarię konkretnej usługi.
Dlatego samo sprawdzenie, że „na mojej macierzy RAID jest wolne miejsce”, nie wystarczy.
Przechowuj stale rosnące dane aplikacji poza dyskiem systemowym
Aktualna dokumentacja ZimaOS zaleca przeniesienie danych aplikacji do rzeczywistej przestrzeni dyskowej zamiast pozwalania, aby bazy danych Dockera, miniatury i pamięci podręczne zapełniały dysk systemowy.
Skorzystaj z aktualnych zaleceń ZimaOS dotyczących pamięci aplikacji, aby zapobiec innemu źródłu przeciążenia dysku systemowego.
Zmiana nazwy pliku files.db pomogła wielu użytkownikom ze społeczności
Jeden z użytkowników społeczności opublikował:
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-filesKilku uczestników odpowiedziało, że przywróciło to działanie Plików.
Nadal należy traktować to jako dodatkową, społecznościową metodę odzyskiwania. Pracownik IceWhale od razu zapytał, jakie znaczenie ma usunięcie bazy danych Plików, i nie zastąpił tym poleceniem oficjalnych zaleceń „zwolnij miejsce na dysku systemowym i uruchom ponownie usługę”.
Zmiana nazwy bazy danych jest bezpieczniejsza niż jej usunięcie, ale nadal zmienia stan aplikacji
Polecenie społecznościowe zachowuje kopię .bak zamiast usuwać bazę danych. Ułatwia to wycofanie zmian, ale odbudowanie bazy danych Plików może zmienić indeksowane metadane lub inny stan usługi.
Nie używaj tej metody jako pierwszego działania, gdy dysk systemowy jest po prostu pełny.
Nie zakładaj, że błąd z wersji 1.5.4 nadal występuje w aktualnym ZimaOS
Obecna wersja ZimaOS to 1.7.x i nadal otrzymuje poprawki dotyczące Plików, pamięci masowej, pamięci operacyjnej, bezpieczeństwa oraz przechowywania danych aplikacji. Historyczny problem jest przydatny, ponieważ pokazuje, jak odróżnić awarię usługi od utraty danych, a nie dlatego, że każdy współczesny błąd Plików ma tę samą przyczynę.
Jeśli problem pojawi się ponownie obecnie, najpierw sprawdź i zapisz ilość wolnego miejsca w systemie, aktualną wersję, stan usługi oraz to, czy dostęp SMB lub inny dostęp do plików nadal działa.
Zwalniaj miejsce w przemyślany sposób
Nie uruchamiaj ogólnych skryptów czyszczących w nieznanych katalogach systemowych. Zidentyfikuj duże pamięci podręczne aplikacji, dane Dockera, kopie zapasowe lub logi i w miarę możliwości korzystaj z aktualnych narzędzi ZimaOS do czyszczenia lub migracji.
Często zadawane pytania dotyczące błędu ładowania Plików
Czy w opisanym przypadku SMB nadal działało?
Tak, co stanowiło mocną przesłankę, że dane i punkty montowania nadal były dostępne.
Co pracownicy IceWhale wskazali jako problem w wersji 1.5.4?
Pełny dysk systemowy, który powodował nieprawidłowe działanie usługi Plików.
Jakie było oficjalne polecenie ponownego uruchomienia usługi?
systemctl restart icewhale-files.
Czy zmiana nazwy pliku files.db była oficjalnym rozwiązaniem pierwszego wyboru?
Nie. Było to społecznościowe obejście potwierdzone przez kilku użytkowników, podczas gdy zaleceniem pierwszego wyboru firmy IceWhale było zwolnienie miejsca i ponowne uruchomienie usługi Plików.
