Użytkownik źródłowy z marca 2026 r. budował pierwszy NAS na cienkim kliencie HP T640 z systemowym dyskiem NVMe o pojemności 128 GB i trzema dyskami twardymi podłączonymi przez USB. Jego plan był rozsądny: przechowywać zdjęcia na jednym dysku zewnętrznym, tworzyć ich kopie zapasowe na drugim, a multimedia Plex umieścić na osobnym dysku o pojemności 4 TB. Główna awaria nie wynikała z tego, że pamięć USB była niemożliwa do wykorzystania. Immich przestał działać, ponieważ mapowania woluminów aplikacji zostały nieprawidłowo zmodyfikowane.
Część wątku dotycząca możliwości pamięci masowej również wymaga obecnie wyraźnego rozgraniczenia czasowego. W marcu 2026 r. użytkownik i odpowiadający mu rozmówca traktowali dyski USB jako bardziej ograniczone niż pamięć wewnętrzną. Aktualna dokumentacja ZimaOS wyraźnie stwierdza, że dyski USB działają według tej samej logiki co wewnętrzne dyski HDD/SSD i mogą służyć do przechowywania danych, być dodawane do macierzy lub wykorzystywane do rozszerzania istniejącej przestrzeni.
Źródłowy NAS był całkowicie zależny od pamięci masowej USB
Konfiguracja obejmowała:
- cienki klient HP T640 z procesorem AMD R1505G, 8 GB pamięci RAM i dyskiem NVMe o pojemności 128 GB;
- dwa dyski HDD Seagate 2,5 cala w osobnych obudowach USB;
- jeden zewnętrzny dysk HDD WD o pojemności 4 TB na multimedia Plex.
Ponieważ cienki klient nie miał wygodnych wewnętrznych zatok na dyski, użytkownik potrzebował, aby pamięć USB działała jak główna pamięć masowa NAS, a nie jak tymczasowy nośnik wymienny.
Dyski pojawiły się jako pamięć masowa USB
Użytkownik uważał, że dysków zewnętrznych nie można traktować tak jak pamięci wewnętrznej ani używać ich w macierzy RAID. Odzwierciedlało to zachowanie i oczekiwania związane z jego konfiguracją z marca 2026 r., a nie obecny model pamięci masowej ZimaOS.
Obecne ZimaOS traktuje dyski USB jak zwykłą pamięć masową
Aktualna dokumentacja IceWhale stwierdza, że dyski USB działają według tej samej logiki co wewnętrzne dyski HDD i SSD: można ich używać jako pojedynczej pamięci masowej, dodawać do macierzy lub wykorzystywać do rozszerzania istniejącej przestrzeni.
Zamiast budować nowy system na starszym założeniu, że RAID przez USB jest kategorycznie nieobsługiwany, użyj obecnego procesu konfiguracji pamięci masowej ZimaOS dla dysków USB.
Awaria Immich wynikała z błędnego mapowania pliku zamiast katalogu
Użytkownik źródłowy zmienił ustawienia woluminów Immich, a Docker zwrócił błąd informujący, że nie można zamontować:
/media/Photos/Immich
→ /etc/localtime/etc/localtime wewnątrz kontenera jest plikiem, a nie katalogiem biblioteki zdjęć. Docker odrzucił więc próbę zamontowania katalogu w miejscu tego pliku.
/etc/localtime mapowanie pliku.Przechowuj zdjęcia i /etc/localtime jako osobne punkty montowania
Autor odpowiedzi ze społeczności prawidłowo rozdzielił te dwie role:
- folder ze zdjęciami na hoście → katalog przesyłania/danych Immich;
- host
/etc/localtimeplik → kontener/etc/localtimeplik.
Aktualne zasady dowiązań bind mount Dockera nadal wymagają zgodności typów źródła i miejsca docelowego. Katalogu nie można zamontować na pliku tak, jakby były wymienne.
Obejście z dowiązaniem bind mount /DATA było historyczną sugestią społeczności
Autor odpowiedzi zasugerował również utworzenie stabilnego katalogu w /DATA i montowanie ścieżki USB za pomocą bind mount, ponieważ dyski zewnętrzne mogą nie być gotowe, gdy aplikacje uruchamiają się po ponownym uruchomieniu.
Były to zalecenia społeczności dotyczące wersji opisanej w źródle. Obecny ZimaOS oferuje lepszą obsługę zarządzanej pamięci USB, dlatego nowa instalacja powinna najpierw korzystać z interfejsu pamięci masowej i selektora zarządzanych woluminów aplikacji, zamiast tworzyć niestandardowe dowiązanie bind mount uruchamiane przy starcie.
Wskaż w Immich zarządzaną pamięć masową, a nie surową ścieżkę urządzenia
Aktualny ZimaOS zaleca umieszczanie danych aplikacji i dużych bibliotek multimediów w przestrzeni pamięci masowej przeznaczonej do ich przechowywania, zamiast zapełniania dysku systemowego. Użyj ścieżki hosta wybranej przez ZimaOS, a następnie zachowaj ścieżkę po stronie kontenera, której oczekuje Immich.
W przypadku aktualnych mapowań aplikacji model ścieżek pamięci aplikacji ZimaOS wyjaśnia, jak łączyć ścieżki hosta i kontenera.
RAID i kopia zapasowa rozwiązują różne problemy
Mimo że obecny ZimaOS może używać dysków USB w macierzach, RAID 1 nie zastępuje drugiej niezależnej kopii zapasowej. Dwa dyski USB w jednej macierzy chronią przed awarią jednego z dysków, ale nie przed przypadkowym usunięciem, złośliwym oprogramowaniem, problemami z obudową lub kontrolerem ani utratą całego serwera NAS.
Pomysł autora źródłowej wypowiedzi dotyczący przechowywania dodatkowej kopii pozostaje użyteczny, mimo że zestaw funkcji pamięci masowej uległ zmianie.
Media Plex są prostsze niż stan aplikacji Immich
Użytkownik uznał dysk Plex o pojemności 4 TB za przeznaczony do wymiany, ponieważ zawartość wideo można było odtworzyć. To rozsądne rozróżnienie ryzyka: pliki multimedialne, zdjęcia Immich, stan bazy danych Immich i konfiguracja aplikacji niekoniecznie wymagają takiej samej nadmiarowości ani zasad tworzenia kopii zapasowych.
Najczęstsze pytania dotyczące zewnętrznej pamięci USB
Czy obecny ZimaOS może używać dysków USB jako zarządzanej pamięci masowej?
Tak. Aktualna dokumentacja pamięci masowej wyraźnie obsługuje dyski USB jako magazyny i członków macierzy.
Dlaczego Immich przestał działać po zmianie katalogu?
Folder ze zdjęciami został przypadkowo zamapowany na /etc/localtime ścieżka pliku.
Czy obecni użytkownicy powinni tworzyć ręczne dowiązania bind mount /DATA dla każdego dysku USB?
Nie. To było historyczne obejście stosowane przez społeczność. Zacznij od aktualnych ustawień zarządzanej pamięci masowej i woluminów aplikacji.
