Att flytta en mediemapp till en annan ZimaOS-enhet uppdaterar inte automatiskt alla Docker-appar som använde den gamla sökvägen. Det var precis det som hände i källan: filmfilerna flyttades till en ny NVMe-enhet, Radarr visade den nya lagringsplatsen, men Jellyfin refererade fortfarande till sin gamla bind-montering och kunde därför inte hitta filmen.
Lösningen är att uppdatera programmets volymsökväg på värdsidan samtidigt som en stabil sökväg på containersidan, till exempel /movies eller /media, behålls. Zima-Giorgio visade både CLI-upptäckt och mappväljaren i det grafiska gränssnittet, och användaren bekräftade direkt att GUI-metoden löste problemet.
Docker har en värdsökväg och en containersökväg
En mappning ser i princip ut så här:
/real/path/on/ZimaOS → /path/inside/appVänstersidan måste peka på den lagringsenhet och mapp där filerna faktiskt finns. Högersidan är den sökväg som Jellyfin/Radarr ser inuti containern.
En andra ZimaOS-lagringsenhet finns inte automatiskt under /DATA
/DATA/...-sökväg angavs skapades en mapp på fel lagringsenhet.Det var den centrala förvirringen. /DATA/extra-movies hänvisade till systemets standardområde för data, inte automatiskt till mappen på den nya NVMe-enheten.
Zima-Giorgio föreslog att kontrollera /media
För att identifiera värdsökvägen manuellt föreslog Giorgio:
ls /mediaVid den tidpunkten visades fristående eller monterade lagringsenheter under /media. Den exakta sökvägen kan variera beroende på aktuell lagringshantering och enhetsnamn, så använd sökvägen som visas i det aktuella gränssnittet i stället för att gissa.
Mappväljaren i GUI:t var lösningen som bekräftades i källan
Aktuella ZimaOS stöder uttryckligen uppdatering av volymsökvägar efter att data har flyttats
IceWhales aktuella dokumentation om appsökvägar anger nu att du kan flytta en apps data till en annan enhet om en enhet blir full och uppdatera sökvägen i appinställningarna utan att installera om appen.
Använd det aktuella arbetsflödet för Docker-sökvägar i ZimaOS.
Behåll containersökvägen stabil när det är möjligt
Om Jellyfin redan använder /Media internt ändrar du endast värdsidan till den nya fysiska mappen. Genom att behålla containersökvägen stabil undviker du att programmets databas eller bibliotek ser en helt annan sökväg.
Uppdatera varje app som mappar den flyttade mappen
Radarr, Sonarr, qBittorrent, Jellyfin, Plex och importverktyg kan ha egna volymmappningar. Att en app ser den nya mappen uppdaterar inte de andra.
Verifiera innan du tar bort den gamla mappen
Öppna en film i Jellyfin, låt Radarr söka igenom rotmappen, testa qBittorrents importsökvägar om det är relevant och bekräfta behörigheterna. Behåll den gamla källmappen tills alla appar använder den nya värdmappningen utan problem.
Att flytta media skiljer sig från att flytta AppData
Film- och TV-mappar är vanliga innehållsbibliotek. AppData kan innehålla SQLite- eller PostgreSQL-databaser, miniatyrbilder, index och programtillstånd som kan kräva att appen stoppas eller att ZimaOS datamigrering används för att säkerställa konsekvens. Hantera därför inte alla volymer som enkla mediemappar som kan dras och släppas.
Kontrollera behörigheterna på den nya lagringsenheten igen
En korrekt ny värdsökväg kan ändå misslyckas om containerns identitet kan läsa den gamla enheten men inte den nya. Efter ommappningen ska du kontrollera att appen kan läsa och, när det krävs, skriva till målmappen utan att ge onödiga skrivbehörigheter för alla användare.
Vanliga frågor om flyttade mediesökvägar
Varför försvann filerna från Jellyfin efter att de flyttats?
Dess Docker-bind-montering pekade fortfarande på den gamla mappen på värdsidan.
Bekräftade användaren i källan att GUI-mappväljaren hjälpte?
Ja. Användaren svarade direkt att hen inte hade känt till att mappväljaren fanns och att den löste förvirringen.
Ska jag skriva /DATA för varje ny lagringsenhet?
Nej. Använd den faktiska värdsökväg som ZimaOS visar eller låter dig välja för den lagringsenheten.
