Källanvändaren hade fått Syncthing att fungera för synkronisering av mobilfoton, men filerna hamnade hela tiden på systemdisken i stället för lagringsdisken. När en sökväg kopierades från appen Filer och klistrades in direkt i Syncthing återskapade Syncthing samma mappstruktur i sitt eget containerfilsystem.
Den slutliga lösningen var konceptuell snarare än ett magiskt filsystemskommando: Docker har en värdsökväg och en containersökväg. Syncthing måste använda den sökväg som är synlig inuti containern, inte den råa sökväg som är synlig för CasaOS eller ZimaOS.
Varför den externa sökvägen återskapades på fel plats
Om Syncthing instrueras att använda en sökväg som den faktiskt inte kan se kan den skapa sökvägen i sitt eget skrivbara filsystem eller i en mappad konfigurationsplats. Källanvändaren tolkade mappnamnet som en sökväg till en extern disk, medan containern tolkade det som en sökväg relativ till sitt eget filsystem.
Hitta den riktiga monteringspunkten på värden
Communityn använde lsblk för att identifiera var operativsystemet hade monterat den externa enheten. I den svarandes exempel visades enheten under en sökväg som liknade /media/devmon/...; den ursprungliga skribentens enheter visades senare under /mnt/Storage1 och /mnt/Storage2.
Dessa exakta historiska monteringssökvägar är exempel från CasaOS/ZimaBlade och ska inte betraktas som aktuella, universella ZimaOS-sökvägar.
Mappa värdens enhet till Syncthing
Svarande personen använde /DATA som sökvägen på Syncthingsidan. När den mappningen finns bör Syncthing hänvisa till mappar under /DATA i stället för den ursprungliga monteringssökvägen på värden.
Användaren angav först värdsökvägen i Syncthing
Syncthing gav då ett behörighets-/sökvägsfel eftersom den interna sökvägen inte motsvarade den mappade volymen.
Den slutgiltiga fungerande sökvägen var /DATA/Documents
Svarande personen förklarade att när värddatorns enhet hade mappats till /DATA, bör Syncthing använda:
/DATA/Documentseller motsvarande ~/Documents som kortform när Syncthings hemkatalog pekar på den mappade dataplatsen.
Den ursprungliga skribenten återkom nästa dag och bekräftade att det fungerade.
Rekursiv chown var en del av communityns arbetsflöde, inte den grundläggande lösningen
Tråden använde också rekursiv chown på den externa enheten. Det kan vara lämpligt på ett Linux-ägt filsystem, men det ändrar ägarskapet för hela målet och var inte ett krav formulerat av IceWhale.
Kör inte en rekursiv ägarändring på en befintlig delad disk innan du vet vilka användare och appar som redan är beroende av dess behörigheter.
Aktuella ZimaOS gör det enklare att mappa applagring
Aktuella ZimaOS dokumenterar värd- och containersökvägar direkt i appinställningarna och rekommenderar att appdata lagras på hanterad lagring i stället för att låta appar fylla systemdisken.
Använd den aktuella modellen för app-sökvägar i ZimaOS för Docker-volymer i stället för att förlita dig på gamla CasaOS-monteringsplatser.
Källanvändaren installerade om Syncthing och byggde om mappningen
Efter att de första försöken förblivit förvirrande installerade trådskaparen om Syncthing, lade till lagringsenheterna igen och mappade /mnt/Storage1 på värden till /DATA inuti containern. Detta rena omtest tog bort gamla containerinställningar ur felsökningen.
Värdbehörighet ensam fick inte den felaktiga containersökvägen att fungera
Användaren kunde logga in via SSH på lagringsenheten och skapa mappar, men Syncthing misslyckades ändå när den ombads använda /mnt/Storage1/Documents internt. Det negativa resultatet är värdefullt: att du kan skriva som värdanvändaren betyder inte att containern kan se samma namnrymd.
Containerns synlighet måste vara korrekt innan justering av behörigheter kan lösa problemet.
Aktuella ZimaOS bör i första hand använda hanterade lagringssökvägar
Tråden handlar om en ZimaBlade som levererades med CasaOS-liknande lagringssökvägar. Aktuella ZimaOS har ett annat beteende för hanterad lagring och ett tydligare gränssnitt för appvolymer. På en aktuell server bör du använda den lagringssökväg som valts via ZimaOS i stället för att anta /mnt/Storage1 eller /media/devmon kommer att finnas.
Ändra bara de behörigheter som appen faktiskt behöver
Syncthing behöver vanligtvis läs- och skrivåtkomst till sin synkroniseringsmapp. Om en mappad mapp visas men inte går att skriva till, kontrollera ägarskap och gruppbehörigheter för just den mappen. Undvik att ändra ägarskapet rekursivt på en hel enhet med flera användningsområden, såvida du inte har tagit hänsyn till alla andra tjänster som använder enheten.
Vanliga frågor om Syncthing och externa hårddiskar
Varför skapade Syncthing sökvägen till den externa enheten på systemdisken?
Värdsökvägen var inte den sökväg som Syncthing kunde se inuti sin container.
Vilken sökväg fungerade efter att enheten hade mappats till /DATA?
Källanvändaren bekräftade /DATA/Documents fungerade.
Var rekursiv chown den enda lösningen?
Nej. Den avgörande insikten var skillnaden mellan värdsökväg och containersökväg.
