Pierwotny cel tego wątku z listopada 2025 roku był prosty: pozostawić ZimaOS i aplikacje na wewnętrznym dysku SSD o pojemności 512 GB w minikomputerze, a zewnętrznego dysku Seagate USB o pojemności 5 TB używać do przechowywania multimediów i plików pobieranych. Problem wynikał z traktowania zewnętrznego dysku jak zwykłego punktu montowania na serwerze Linux, zanim zrozumiano, że ZimaOS już zarządza pamięcią masową.
Użytkownik eksperymentował z ręcznym montowaniem w /var, później serwer uległ awarii, a użytkownik ponownie zainstalował ZimaOS. Następnie zamontował dysk w ścieżce danych ZimaOS i zmapował ją w SABnzbd, ale aplikacja nadal zwracała błąd uprawnień. Ten wątek zawiera więc dwie odrębne lekcje: najpierw wybierz bezpieczną ścieżkę hosta zarządzaną przez system, a następnie osobno rozwiąż uprawnienia kontenera.
Nie używaj /var jako dowolnego punktu montowania USB
ZimaOS to system operacyjny w stylu urządzenia, z zarządzanymi ścieżkami systemowymi. Użytkownik źródłowy wspomniał o zamontowaniu dysku zewnętrznego w /var Początkowo wydawało się, że działa, ale później doszło do całkowitej awarii serwera i ponownej instalacji.
Wątek nie dowodzi, że samo zamontowanie bezpośrednio spowodowało awarię, ale stanowi wystarczający powód, aby nie promować katalogów systemowych do roli zwykłych lokalizacji pamięci masowej dla dysków z multimediami.
Pozwól, aby bieżąca wersja ZimaOS zarządzała dyskiem zewnętrznym
Obecna wersja ZimaOS oferuje znacznie szersze wsparcie dla pamięci USB niż środowisko z 2025 roku opisane w tym wątku. Dysk USB można dodać w Ustawieniach > Pamięć masowa, a następnie używać go jako zwykłej pamięci masowej, zamiast ręcznie podpinać go do wymyślonego punktu montowania w systemie Linux.
W przypadku nowego wdrożenia zacznij od bieżącego procesu ZimaOS dodawania pamięci USB. Po zarządzaniu dyskiem użyj jego rzeczywistego folderu pamięci masowej w mapowaniu woluminów aplikacji.
Dysk źródłowy ostatecznie pojawił się w ścieżkach zarządzanych przez ZimaOS
Dokładnej ścieżki pokazanej w instalacji z 2025 roku nie należy kopiować na inny serwer. Nazwy urządzeń, takie jak sda, sdb, oraz sdc może się zmieniać w zależności od kolejności uruchamiania i podłączonego sprzętu.
Zamapuj folder, nie surowe urządzenie blokowe
Aplikacje Dockera powinny zwykle otrzymywać katalog, taki jak folder pobierania lub multimediów, a nie surowe urządzenie /dev/sda1. ZimaOS montuje system plików, a kontener otrzymuje folder z hosta znajdujący się na tym zamontowanym systemie plików.
Obecne wyjaśnienie sposobu, w jaki pamięć masowa hosta staje się wolumenem kontenera pomaga uniknąć mylenia urządzenia dyskowego, punktu montowania i ścieżki kontenera.
Prawidłowe zamontowanie nadal może powodować błąd uprawnień
Użytkownik źródłowy dotarł do /DATA/HDD1 i zamapowano go w SABnzbd, ale aplikacja nie mogła używać wybranego katalogu pobierania. Oznacza to, że widoczność pamięci masowej nie była już jedynym problemem.
Procesy Dockera działają jako użytkownik lub grupa wewnątrz kontenera. Jeśli folder na hoście należy do innego użytkownika i ma restrykcyjne uprawnienia, kontener może widzieć ścieżkę, ale nadal nie móc tworzyć plików.
Nie kopiuj bezmyślnie PUID 999
W jednej z odpowiedzi społecznościowych zalecono użytkownikowi zmianę PUID z 1000 na 999. Mogło to odpowiadać modelowi kont ZimaOS u autora odpowiedzi, ale nie jest uniwersalną stałą.
Przed zmianą PUID lub PGID ustal właściciela rzeczywistego folderu na hoście oraz użytkownika, jako który aplikacja ma działać. Wartość liczbowa działająca w jednej instalacji może wskazywać inne konto w innej.
Rekursywne chmod i chown są potężne i destrukcyjne
W późniejszej odpowiedzi społeczność zasugerowała rekursywne użycie polecenia chmod 775 oraz chown w ścieżce pobierania. Te polecenia mogą być przydatnymi narzędziami administracyjnymi systemu Linux, ale zmieniają każdy plik i katalog w określonym miejscu docelowym. Nie zostały opublikowane przez pracowników IceWhale w tym wątku.
Przed rekursywną zmianą właściciela:
- potwierdź dokładną ścieżkę docelową;
- potwierdź, że system plików obsługuje standardowe uprawnienia właściciela w systemie Linux;
- ustal, którzy użytkownicy lub usługi już korzystają z tego folderu;
- wykonaj kopię zapasową ważnych metadanych lub uprawnień, jeśli z folderu korzysta kilka aplikacji.
Typ systemu plików może zmienić model uprawnień
Dysk z systemem ext4 przechowuje bezpośrednio identyfikatory UID, GID i bity uprawnień systemu Linux. exFAT i niektóre konfiguracje NTFS mogą zamiast tego prezentować właściciela za pomocą opcji montowania. Jeśli zmiana PUID nie przynosi skutku, przed wielokrotną zmianą ustawień aplikacji sprawdź system plików.
Bardziej przejrzysty układ dla aplikacji multimedialnych
Praktyczny układ wygląda następująco:
- wewnętrzny dysk SSD: system ZimaOS i małe środowisko uruchomieniowe aplikacji;
- duży zewnętrzny dysk HDD: multimedia, pobrane pliki, kopie zapasowe i inne duże ilości danych;
- trwałe dane aplikacji: umieszczone w lokalizacji pamięci masowej o wystarczającej pojemności i objętej kopią zapasową;
- dla każdej aplikacji: jawne mapowania woluminów wyłącznie do potrzebnych jej folderów.
Dzięki temu pobierane multimedia nie zapełnią dysku systemowego, a konfigurację aplikacji będzie można łatwiej tworzyć oddzielnie od dużych plików multimedialnych.
Często zadawane pytania dotyczące zewnętrznych dysków HDD w ZimaOS
Czy powinienem ręcznie zamontować zewnętrzny dysk HDD w katalogu /var?
Nie w przypadku typowego, aktualnego użycia ZimaOS. Użyj interfejsu Pamięć masowa i zarządzanych ścieżek pamięci.
Czy SABnzbd powinien bezpośrednio mapować /dev/sda1?
Nie. Zmapuj zwykły katalog hosta z zamontowanego systemu plików na ścieżkę pobierania oczekiwaną przez kontener.
Dlaczego aplikacja widzi folder, ale nie może w nim zapisywać?
Uprawnienia systemu plików hosta, właściciel plików lub PUID/PGID kontenera mogą nie zezwalać na zapis.
Czy PUID 999 to standardowa wartość w ZimaOS?
Nie. Była to sugestia dotycząca konkretnej społeczności i należy ją zweryfikować w rzeczywistym systemie.
