Gdy polecenia chown i chmod pozornie nic nie zmieniają na dysku USB, najpierw ustal typ systemu plików. W odpowiedzi społeczności podejrzewano NTFS lub exFAT — to rozsądne wyjaśnienie, ponieważ te systemy plików nie działają tak jak ext4/Btrfs, które natywnie obsługują uniksowych właścicieli i bity uprawnień.
Źródło nie podaje, którego systemu plików faktycznie użył MikeFrizz, a autor pierwotnego wpisu nie wrócił z potwierdzonym wynikiem. Dlatego ten tekst powinien pozostać przewodnikiem po rozwiązywaniu problemów zależnym od systemu plików, a nie stwierdzeniem, że każdy dysk USB w ZimaOS ignoruje uprawnienia.
Zidentyfikuj system plików USB przed zmianą uprawnień
Sprawdź format dysku w sekcji Pamięć masowa ZimaOS albo za pomocą polecenia tylko do odczytu, takiego jak:
lsblk -fObecna wersja ZimaOS obsługuje odczyt i zapis danych na dyskach NTFS, exFAT, ext4 i Btrfs, a także w innych formatach, jednak „obsługa odczytu i zapisu” nie oznacza, że wszystkie systemy plików zachowują metadane uniksowych UID/GID i trybów dostępu w ten sam sposób.
Skorzystaj z aktualnej tabeli obsługiwanych formatów dysków.
NTFS i exFAT często prezentują uprawnienia za pomocą opcji montowania
W systemie Linux exFAT i wiele konfiguracji montowania NTFS prezentuje pliki z wartościami właściciela i trybu dostępu wynikającymi z opcji montowania, zamiast przechowywać zwykłe zmiany uprawnień POSIX dokładnie tak jak ext4. W rezultacie chown lub chmod mogą wydawać się nieskuteczne albo ich efekty mogą znikać po ponownym zamontowaniu dysku.
Nie oznacza to, że dysk jest tylko do odczytu lub uszkodzony.
Linuksowy system plików zapewnia Dockerowi najbardziej przewidywalne uprawnienia POSIX
Jeśli dysk USB jest przeznaczony wyłącznie do ZimaOS/Linux i potrzebujesz rzeczywistej kontroli nad UID/GID oraz trybami dostępu, ext4 lub Btrfs będzie bardziej naturalnym wyborem. Formatowanie jest operacją destrukcyjną, więc przed zmianą systemu plików skopiuj dane w inne miejsce.
Nie używaj dowiązania symbolicznego na hoście jako głównej metody przenoszenia danych Dockera
Użytkownik z opisu skopiował dane Immich na USB i utworzył dowiązanie symboliczne ze starej lokalizacji. Kontenery nie podążają automatycznie za dowiązaniami symbolicznymi na hoście, prowadzącymi poza ich przestrzeń nazw zamontowanych woluminów. Dowiązanie może wskazywać ścieżkę, której kontener nie widzi.
Bezpośrednie montowanie wiązania lub woluminu jest czytelniejsze i łatwiejsze do sprawdzenia.
Zamontuj folder USB bezpośrednio w Immich
Zamiast zachowywać starą ścieżkę na hoście i przekierowywać ją za pomocą dowiązania symbolicznego, edytuj wolumin aplikacji lub kontenera Immich tak, aby rzeczywisty folder USB był zamontowany w ścieżce kontenera oczekiwanej przez Immich.
Aktualna dokumentacja IceWhale wyjaśnia, że ścieżkę na hoście można zmienić bez zmiany ścieżki po stronie kontenera.
Skorzystaj z aktualnego modelu ścieżek woluminów Docker w ZimaOS.
Nie przenoś bez zastanowienia wszystkich komponentów Immich do dowolnej pamięci USB
Biblioteki multimediów i pamięć przesyłanych plików Immich mają inne wymagania niż baza danych PostgreSQL i stan aplikacji. Przed przeniesieniem katalogów dokładnie ustal, który wolumin na hoście jest przenoszony, i postępuj zgodnie z aktualnymi wytycznymi Immich dotyczącymi wdrażania i migracji.
Nie przenoś aktywnego katalogu bazy danych za pomocą dowiązania symbolicznego, gdy kontenery są uruchomione.
Najpierw napraw mapowanie, zamiast od razu używać chmod 777
Jeśli kontener nie widzi właściwego folderu na hoście, zmiana uprawnień nie naprawi ścieżki. Najpierw zweryfikuj montowanie, a następnie przyznaj kontenerowi tylko minimalny wymagany dostęp użytkownika lub grupy.
Często zadawane pytania dotyczące uprawnień na USB
Czy ZimaOS obsługuje odczyt i zapis na NTFS oraz exFAT?
Tak, aktualna dokumentacja IceWhale wymienia oba systemy jako obsługiwane w trybie odczytu i zapisu.
Dlaczego chmod/chown mogą nadal działać inaczej?
Te systemy plików nie używają natywnej linuksowej semantyki właścicieli i trybów dostępu POSIX w taki sam sposób jak ext4 lub Btrfs.
Czy system plików użytkownika ze źródła i ostateczne rozwiązanie zostały potwierdzone?
Nie. System plików został wywnioskowany przez uczestnika społeczności, a autor pierwotnego wpisu nie poinformował o wyniku.
