Als Plex, Radarr, Sonarr of een andere Docker-app na elke herstart van ZimaOS de toegang tot een externe SMB-NAS verliest, controleer dan de hostkoppeling voordat je de applicatie wijzigt. De container kan een netwerkshare alleen zien als ZimaOS deze succesvol heeft gekoppeld en het Docker-bindpad nog naar die gekoppelde locatie verwijst.
In een communitygeval met een Synology-share werd de toegang telkens hersteld nadat de gebruiker dezelfde map opnieuw had geselecteerd in de padkiezer van Docker Compose. Dat wijst sterk op een probleem met het behouden van de koppeling of het pad, maar de uitleg op het forum dat ZimaOS altijd een nieuwe interne koppelings-ID genereerde, was een redenering uit de community en geen door IceWhale bevestigde hoofdoorzaak. Een goede handleiding moet daarom de koppeling, het pad en de opstartvolgorde afzonderlijk onderzoeken.
Controleer eerst of de SMB-share na het opnieuw opstarten is gekoppeld
Open ZimaOS Bestanden en blader naar de share op de externe NAS voordat je Plex of Radarr opent. Als de share zelf niet beschikbaar is, ligt het eerste probleem niet bij de Docker-app.
Als de share ontbreekt
Controleer of de externe NAS online is, het IP-adres/de hostnaam nog steeds wordt gevonden, SMB is ingeschakeld en de opgeslagen aanmeldgegevens nog geldig zijn. Verbind de share indien nodig opnieuw via de workflow voor ZimaOS-netwerkopslag.
Als de share zichtbaar is in Bestanden
Ga daarna verder met de Docker-koppeling. De hostkoppeling bestaat, maar de applicatie verwijst mogelijk nog naar een verouderd of niet-beschikbaar pad.
Gebruik ZimaOS-netwerkopslag in plaats van een handmatig fstab-item
De gebruiker overwoog het bewerken van /etc/fstab. Dat is niet de beste eerste oplossing op een appliance-achtig besturingssysteem dat netwerkopslag al via de gebruikersinterface beheert.
De huidige ZimaOS-documentatie beschrijft SMB-gebaseerde toegang tot een andere NAS als onderdeel van de workflows voor migratie en netwerkopslag. Gebruik eerst die beheerde route, zodat ZimaOS referenties en de koppelstatus consistent kan beheren.
De migratiehandleiding voor ZimaOS NAS bevat de huidige referentie.
Controleer het Docker-hostpad, niet alleen het containerpad
Docker-volumekoppelingen hebben twee zijden:
- hostpad: waar ZimaOS de gekoppelde Synology-map ziet;
- containerpad: het stabiele pad dat Plex, Radarr of Sonarr in de container ziet.
Als de hostzijde na een herstart ongeldig is, kan het containerpad er in de gebruikersinterface van de toepassing nog steeds correct uitzien terwijl het naar niets bruikbaars verwijst.
De huidige handleiding voor Docker-paden in ZimaOS legt dit onderscheid uit.
Selecteer de map één keer opnieuw als diagnostische test
Als de externe share zichtbaar is in Bestanden maar de app er geen toegang toe heeft, open dan de app- of Compose-configuratie en selecteer de hostmap opnieuw met de padkiezer van ZimaOS.
Als de toegang onmiddellijk terugkeert zonder de inloggegevens of containerpaden te wijzigen, is dat sterk bewijs dat de fout zich bevindt tussen de beheerde koppeling en de Docker-bindkoppeling.
Controleer de opstartvolgorde na elke herstart
Externe SMB-opslag is afhankelijk van netwerken, DNS/IP-bereikbaarheid, authenticatie en het beschikbaar zijn van de NAS. Docker-containers kunnen sneller starten dan de externe koppeling beschikbaar komt.
Eenvoudige test
- start ZimaOS opnieuw op;
- wacht totdat de externe share zichtbaar is in Bestanden;
- start alleen de betreffende Docker-app opnieuw;
- controleer of media of downloads terugkomen.
Als dat betrouwbaar werkt, is het pad mogelijk stabiel en ligt het echte probleem wellicht bij de opstarttiming in plaats van bij veranderende koppelingsidentifiers.
Controleer de machtigingen op beide systemen
De Synology-account die voor de SMB-koppeling wordt gebruikt, moet toegang hebben tot de mediamappen. Vervolgens moet de ZimaOS-koppeling toegankelijk zijn voor het Docker-proces. Ten slotte moet de toepassing het juiste containerpad gebruiken.
Problemen met machtigingen kunnen lijken op een ontbrekende koppeling. Controleer daarom afzonderlijk op ‘toegang geweigerd’ en op ‘pad niet gevonden’ of ‘bestand bestaat niet’.
Waarom handmatige wijzigingen in fstab herstel moeilijker kunnen maken
Een aangepaste mount kan referentiesbestanden, opstartafhankelijkheden, timingopties en foutgedrag introduceren die ZimaOS niet in zijn gebruikersinterface beheert. Als die aangepaste mount tijdens het opstarten mislukt, kunnen apps toch starten met een lege map als doel.
Gebruik fstab alleen wanneer de beheerde workflow voor netwerkopslag niet aan een vereiste kan voldoen en je bereid bent de mount bij updates te onderhouden.
Media-apps veerkrachtiger maken
- Gebruik een stabiel NAS-IP-adres of een betrouwbare lokale DNS-naam.
- Houd de externe share geconfigureerd via Network Storage.
- Koppel één stabiele hostmap aan de container.
- Gebruik hetzelfde containerpad consistent in Radarr, Sonarr, downloadclients en mediaservers.
- Controleer na updates of opslagwijzigingen de mount voordat je applicatiebibliotheken wijzigt.
De LAN-probleemoplossingsgids helpt vaststellen of de fout op de netwerklaag begint, terwijl de basisprincipes van Docker-paden de Docker-context bieden.
Veelgestelde vragen
Waarom raken mijn Docker-apps een Synology-share kwijt nadat ZimaOS opnieuw is opgestart?
De meest waarschijnlijke oorzaken zijn dat de SMB-share niet opnieuw wordt gekoppeld, dat de app een verouderd hostpad gebruikt of dat de container start voordat de externe share gereed is. Test deze oorzaken afzonderlijk.
Moet ik /etc/fstab bewerken?
Niet als eerste oplossing. Geef de voorkeur aan ZimaOS Network Storage, zodat het systeem de share beheert. Handmatige mounts zorgen voor extra onderhoud en complexiteit rond de opstartvolgorde.
Waarom werkt de app weer als ik dezelfde map opnieuw selecteer?
Hiermee wordt de bindkoppeling aan de hostzijde vernieuwd. Dat wijst op een mount-/padprobleem, zelfs als de zichtbare mapnaam niet is gewijzigd.
Kan ik een externe SMB-share gebruiken voor Plex- en Arr-apps?
Ja, mits ZimaOS het betrouwbaar koppelt, de machtigingen correct zijn en alle containers consistente host- en containerpaden gebruiken.
