Den här källan började som ett frustrerande behörighetsproblem och utvecklades så småningom till en lösning som kan upprepas. Syncthing kunde kommunicera med Windows-motparten och synkronisera till sin standardsökväg i AppData, men ett försök att använda en monterad NAS-sökväg som t.ex. /media/raid/NAS/Music orsakade behörighet nekad och mappsökväg saknas fel.
I augusti 2025 publicerade en användare i communityn den metod som fungerade för dem: installera om Syncthing med Custom Install, använd den riktiga ZimaOS-användarens PUID/PGID, välj en lämplig synkroniseringsrot och låt Syncthing skapa sin egen målmapp. Två senare användare bekräftade uttryckligen att detta fungerade. IceWhales aktuella officiella Syncthing-guide dokumenterar nu i princip samma konfiguration.
Den ursprungliga Syncthing kunde bara skriva till sin standardsökväg i AppData
Källanvändaren kunde fylla i:
/DATA/AppData/syncthing/config/Syncmen kunde inte använda den önskade musikmappen på hårddisken, trots att Files, Jellyfin och Navidrome kunde komma åt den. Det är starka belägg för en felaktig containeridentitet eller behörighetskonfiguration snarare än en defekt disk.
Att köra Syncthing som root föreslogs, men är inte den aktuella rekommenderade lösningen
Ett tidigt svar från communityn föreslog PUID/GUID 0. Att köra en filsynkroniseringstjänst som root kan kringgå många behörighetsproblem, men ger också containern betydligt större möjlighet att skriva och radera än nödvändigt.
IceWhales aktuella vägledning rekommenderar uttryckligen att den riktiga användarens ID:n används i stället.
Använd Custom Install
Hitta den faktiska ZimaOS-användarens PUID och PGID
Den aktuella officiella vägledningen använder:
id -u användarnamn
id -g användarnamnErsätt användarnamn med det ZimaOS-konto som ska äga och hantera de synkroniserade filerna, och kopiera sedan de returnerade numeriska ID:na till Syncthings miljövariabler.
Använd inte roten på en monterad disk som Syncthings mapp
I IceWhales aktuella dokumentation står att roten på en monterad disk eller systemmappar som Gallery/Media/Documents inte bör användas direkt som Syncthings mappsökväg, eftersom detta normalt kräver behörigheter på rotnivå.
Skapa eller använd i stället en lämplig dedikerad undermapp.
Låt Syncthing skapa målmappen
Communitylösningen varnade uttryckligen användare för att skapa målmappen i förväg via ZimaOS Files webbläsare. Den aktuella officiella dokumentationen upprepar nu samma bästa praxis: definiera målet i Syncthing och låt Syncthing skapa det.
Den här community-lösningen återspeglas nu i den officiella ZimaOS-dokumentationen
Använd den aktuella Syncthing-konfigurationen för ZimaOS.
Varför guiden varnar för att felaktiga ID:n kan kräva ominstallation
Om den första installationen skapar konfiguration och mappar under fel identitet kan det räcka med att ändra ett enda värde senare för att gammalt ägarskap ska finnas kvar. Aktuella riktlinjer ber därför användare att noggrant kontrollera PUID/PGID före installationen.
Säkerhetskopiera Syncthings konfiguration om den innehåller viktiga relationer mellan enheter och mappar innan du raderar AppData för en ren ominstallation.
Testa först med en liten mapp som kan kastas
Innan du riktar Syncthing mot ett stort musik- eller dokumentträd bör du synkronisera en liten testmapp, verifiera tvåvägsbeteendet om det är aktiverat, bekräfta ägarskapet på NAS:en och därefter lägga till produktionsmappar.
Åtgärden fungerar eftersom alla behörighetslager till slut överensstämmer
För att Syncthing ska kunna skapa filer måste fyra saker stämma överens: ZimaOS-värdmappen finns och är skrivbar för den avsedda användaren/gruppen, Docker mappar värdmappen till containern, Syncthing körs med motsvarande PUID/PGID och mappsökvägen som konfigurerats i Syncthing pekar på monteringen inne i containern. En avvikelse i något av dessa lager kan ge samma symtom: ”åtkomst nekas”.
Varför rötter på monterade diskar är ett dåligt standardmål för synkronisering
Roten på en monterad disk innehåller ofta systemhanterade kataloger, delningsmetadata eller behörigheter avsedda för flera tjänster. Om en synkroniseringsmotor får bred skrivåtkomst där ökar konsekvenserna av oavsiktliga borttagningar eller felkonfiguration. Med en dedikerad undermapp blir det mycket enklare att förstå ägarskap och säkerhetskopieringspolicy.
Verifiera Syncthings borttagningsbeteende innan du aktiverar tvåvägssynkronisering
Syncthing sprider ändringar enligt mappens läge, inklusive borttagningar i sändnings-/mottagningskonfigurationer. Innan du riktar den mot ett stort musik- eller dokumentbibliotek bör du testa hur skapande, namnändring och borttagning fungerar med filer som kan kastas, och överväga Syncthings versionshantering om det är viktigt att kunna återställa oavsiktliga fjärrborttagningar.
Vanliga frågor om Syncthing på ZimaOS
Bekräftade senare användare att PUID/PGID-metoden fungerade?
Ja. Minst två senare deltagare i källan sade uttryckligen att den publicerade metoden löste deras problem.
Bör Syncthing köras som root för att få åtkomst till diskar?
Aktuella riktlinjer från IceWhale rekommenderar i stället att du använder den riktiga ZimaOS-användarens PUID/PGID och en lämplig undermapp.
Bör jag skapa målmappen i ZimaOS Filer först?
Aktuell IceWhale-dokumentation säger att Syncthing ska skapa målmappen själv.
