Rozwiązanie społecznościowe

SABnzbd traci zewnętrzny udział SMB po ponownym uruchomieniu ZimaOS: czas montowania, awaryjne użycie folderu lokalnego i bezpieczniejszy plik fstab

A March 2026 thread where SABnzbd pointed directly at a ZimaOS-mounted Synology SMB path under /media. After reboot the remote share was not ready when the container started, so downloads could land in a local directory at the same path. The user later confirmed manual CIFS mounts persisted through reboot with /etc/fstab, but bad mount paths and spaces in mountpoints caused boot failures until corrected. This was community troubleshooting, not an IceWhale-supported fstab recipe.

Problem źródłowy był poważniejszy niż znikająca ścieżka. Po ponownym uruchomieniu SABnzbd mógł uruchomić się, zanim udział SMB na serwerze Synology został faktycznie zamontowany. Kontener nadal widział katalog pod oczekiwaną ścieżką hosta, więc pobieranie mogło się zakończyć i wyglądać na pomyślnie przeniesione — podczas gdy w rzeczywistości plik trafiał do lokalnego magazynu ZimaOS zamiast na zdalny serwer NAS.

Społeczność ostatecznie opracowała działające ręczne rozwiązanie z CIFS/fstab, a autor oryginalnego wpisu potwierdził, że montowanie utrzymywało się po ponownym uruchomieniu. Zademonstrował jednak także ryzyko: nieprawidłowy wpis w fstab mógł uniemożliwić normalne uruchomienie systemu, a punkt montowania zawierający nieescapowaną spację powodował nieprawidłowe działanie konfiguracji. Traktuj te polecenia jako potwierdzone przez społeczność czynności administracyjne, a nie jako aktualną oficjalną procedurę ZimaOS dotyczącą magazynu sieciowego.

Główną przyczyną awarii był moment montowania

Ścieżka źródłowa wyglądała tak:

/media/192.168.2.125/Movies

Po ponownym uruchomieniu montowanie SMB nie było gotowe, gdy uruchamiał się SABnzbd. Ponowne dodanie tego samego woluminu po zakończeniu uruchamiania systemu przywracało działanie, co zdecydowanie wskazuje na problem z kolejnością lub czasem uruchamiania, a nie na zmianę identyfikatora montowania.

Brak zdalnego montowania może zmienić się w pułapkę lokalnego katalogu

Jeśli Docker otrzyma ścieżkę katalogu hosta, która istnieje lokalnie, gdy zdalny system plików jest niedostępny, aplikacja może zapisywać dane w tym lokalnym katalogu. W dzienniku nadal może pojawić się informacja o przeniesieniu pliku do /movies, mimo że na serwerze Synology nic się nie pojawi.

Przed rozpoczęciem dużych pobierań sprawdź, czy oczekiwany zdalny system plików jest rzeczywiście zamontowany, a nie tylko to, czy istnieje katalog punktu montowania.

Społeczność przeniosła montowanie do stabilnej ścieżki /DATA

Zaproponowana konfiguracja zakładała zamontowanie udziału SMB w stabilnej lokalnej ścieżce, takiej jak:

/DATA/Media/Movies

a następnie przypisanie tej stabilnej ścieżki hosta do SABnzbd. Dzięki temu ścieżka w kontenerze pozostaje przewidywalna, a zdalny system plików jest zarządzany na poziomie hosta.

Użytkownik źródłowy potwierdził, że /etc/fstab działało po ponownym uruchomieniu

Przykład społeczności używał opcji CIFS, w tym _netdev, konkretnej wersji protokołu SMB oraz wartości UID/GID i uprawnień. Użytkownik poinformował, że wpis w fstab zachowywał się i działał po ponownym uruchomieniu.

Nie umieszczaj danych uwierzytelniających bezpośrednio w konfiguracji dostępnej do odczytu dla wszystkich bez rozważenia użycia chronionego pliku z danymi uwierzytelniającymi.

nofail stało się kluczowe po tym, jak błędny wpis zablokował uruchamianie

Użytkownik źródłowy odkrył, że nieprawidłowe lub niedostępne montowanie mogło zakłócać uruchamianie systemu. W odpowiedzi zalecono opcję nofail, aby ZimaOS mógł kontynuować uruchamianie, jeśli zdalny serwer NAS będzie niedostępny.

_netdev informuje również system montowania, że jest to zasób zależny od sieci.

Spacje w punktach montowania muszą być obsługiwane prawidłowo

Drugi wpis fstab nie zadziałał, ponieważ punkt montowania zawierał TV Shows. W fstab białe znaki oddzielają pola, dlatego spację należy odpowiednio uciec albo unikać jej, używając prostszej nazwy katalogu, takiej jak TV_Shows.

Autor oryginalnego wpisu później z powodzeniem użył osobnego folderu bez spacji.

Zawsze przetestuj konfigurację poleceniem mount -a przed ponownym uruchomieniem

Najbezpieczniejszym krokiem wskazanym w źródle było:

sudo mount -a

Jeśli polecenie zwróci błąd, popraw składnię lub ścieżkę w fstab przed ponownym uruchomieniem. Upewnij się również, że zamontowany system plików zawiera oczekiwane pliki zdalne.

Jeśli spełnia wymagania, preferuj aktualny magazyn sieciowy ZimaOS

Obecna wersja ZimaOS może łączyć się z magazynami SMB/LAN za pośrednictwem przepływów pracy Pliki/Magazyn sieciowy. Najpierw użyj zarządzanego interfejsu, jeśli zapewnia wymaganą przez aplikację trwałość i kolejność uruchamiania.

Zobacz bieżącą procedurę łączenia z udziałem SMB serwera Synology.

Naprawdę niezawodny kontener nie powinien zapisywać danych przed zweryfikowaniem zdalnego montowania

Nawet przy użyciu fstab sieciowy serwer NAS może później przestać być dostępny. W przypadku istotnych przepływów pobierania i importowania dodaj kontrolę stanu lub procedurę uruchamiania, która potwierdzi zamontowanie zdalnego celu, zanim SABnzbd zacznie przetwarzać zadania.

Najczęściej zadawane pytania dotyczące montowania SMB w SABnzbd

Czy źródło potwierdziło, że identyfikator montowania SMB zmienił się po ponownym uruchomieniu?

Nie. Dowody wskazywały na problem z momentem montowania.

Czy fstab działało po ponownym uruchomieniu u użytkownika źródłowego?

Tak, ale nieprawidłowe lub niedostępne wpisy również powodowały problemy z uruchamianiem do czasu ich poprawienia.

Dlaczego pobieranie może wyglądać na zakończone pomyślnie, gdy na serwerze Synology nie ma pliku?

Aplikacja może zapisywać dane w lokalnym katalogu punktu montowania, gdy zdalny system plików SMB nie jest faktycznie zamontowany.