Deze bron begon als een frustrerend probleem met rechten en mondde uiteindelijk uit in een herhaalbare oplossing. Syncthing kon communiceren met de Windows-peer en kon synchroniseren naar de standaardlocatie in AppData, maar bij het gebruik van een gekoppeld NAS-pad zoals /media/raid/NAS/Music veroorzaakte toegang geweigerd en mappad ontbreekt fouten.
In augustus 2025 plaatste een gebruiker uit de gemeenschap de aanpak die voor hen werkte: installeer Syncthing opnieuw met Aangepaste installatie, gebruik de echte PUID/PGID van de ZimaOS-gebruiker, kies een geschikte synchronisatieroot en laat Syncthing zijn eigen bestemmingsmap aanmaken. Twee latere gebruikers bevestigden expliciet dat dit werkte. De huidige officiële Syncthing-handleiding van IceWhale beschrijft nu in wezen dezelfde configuratie.
De oorspronkelijke Syncthing kon alleen naar het standaardpad in AppData schrijven
De brongebruiker kon het volgende invullen:
/DATA/AppData/syncthing/config/Syncmaar kon het gewenste muziekpad op de harde schijf niet gebruiken, hoewel Files, Jellyfin en Navidrome er wel toegang toe hadden. Dat is sterk bewijs voor een verschil in containeridentiteit of -rechten, en niet voor een defecte schijf.
Syncthing als root uitvoeren werd voorgesteld, maar is niet de huidige aanbevolen oplossing
In een vroege reactie uit de gemeenschap werden PUID/GUID 0 voorgesteld. Een bestandsynchronisatieservice als root uitvoeren kan veel problemen met rechten omzeilen, maar geeft de container ook veel ruimere mogelijkheden om te schrijven en verwijderen dan nodig is.
De huidige richtlijnen van IceWhale raden expliciet aan om in plaats daarvan de ID's van de echte gebruiker te gebruiken.
Gebruik een aangepaste installatie
De werkelijke PUID en PGID van de ZimaOS-gebruiker achterhalen
De huidige officiële richtlijnen gebruiken:
id -u gebruikersnaam
id -g gebruikersnaamVervang gebruikersnaam met het ZimaOS-account dat eigenaar moet zijn van de gesynchroniseerde bestanden en deze moet beheren, en kopieer vervolgens de geretourneerde numerieke ID's naar de omgevingsvariabelen van Syncthing.
Gebruik niet de hoofdmap van een gekoppelde schijf als Syncthing-map
In de huidige documentatie van IceWhale staat dat de hoofdmap van een gekoppelde schijf of systeemmappen zoals Gallery/Media/Documents niet rechtstreeks als mappad van Syncthing mogen worden gebruikt, omdat hiervoor normaal gesproken rechten op rootniveau nodig zijn.
Maak in plaats daarvan een geschikte speciale submap aan of gebruik er een.
Laat Syncthing de bestemmingsmap aanmaken
De gemeenschapsoplossing waarschuwde gebruikers er specifiek voor om de bestemming niet vooraf aan te maken via de ZimaOS-bestandsbrowser. In de huidige officiële documentatie wordt nu dezelfde best practice herhaald: definieer de bestemming in Syncthing en laat Syncthing deze aanmaken.
Deze communityoplossing is nu opgenomen in de officiële documentatie van ZimaOS
Gebruik de huidige Syncthing-configuratie voor ZimaOS.
Waarom de handleiding waarschuwt dat onjuiste ID's mogelijk een herinstallatie vereisen
Als de eerste installatie configuratie en mappen onder de verkeerde identiteit aanmaakt, kan het simpelweg later wijzigen van één waarde ervoor zorgen dat het oude eigenaarschap blijft bestaan. Daarom vraagt de huidige richtlijn gebruikers om de PUID/PGID vóór de installatie zorgvuldig te controleren.
Maak een back-up van de Syncthing-configuratie als deze belangrijke relaties tussen apparaten en mappen bevat, voordat je AppData verwijdert voor een schone herinstallatie.
Test eerst met een kleine wegwerpmap
Voordat je Syncthing naar een grote muziek- of documentstructuur laat verwijzen, synchroniseer je eerst een kleine testmap, controleer je het gedrag in twee richtingen als dat is ingeschakeld, bevestig je het eigenaarschap op de NAS en voeg je daarna de productiemappen toe.
De oplossing werkt omdat alle machtigingslagen uiteindelijk overeenkomen
Om Syncthing succesvol bestanden te laten aanmaken, moeten vier zaken op elkaar aansluiten: de hostmap van ZimaOS bestaat en is beschrijfbaar voor de beoogde gebruiker/groep, Docker koppelt die hostmap aan de container, Syncthing wordt uitgevoerd met de overeenkomende PUID/PGID en het in Syncthing geconfigureerde mappad verwijst naar het mountpunt aan de containerzijde. Een afwijking in een van deze lagen kan eruitzien als hetzelfde symptoom: 'permission denied'.
Waarom de hoofdmap van een aangekoppelde schijf geen goede standaarddoelmap is
De hoofdmap van een aangekoppelde schijf bevat vaak systeembeheerde mappen, metadata voor gedeelde mappen of machtigingen die bedoeld zijn voor meerdere services. Door een synchronisatie-engine daar brede schrijftoegang te geven, vergroot je de impact van onbedoelde verwijderingen of een verkeerde configuratie. Met een speciale submap zijn eigenaarschap en back-upbeleid veel eenvoudiger te overzien.
Controleer de verwijderingssemantiek van Syncthing voordat je tweerichtingssynchronisatie inschakelt
Syncthing verspreidt wijzigingen volgens de modus van de map, waaronder verwijderingen in configuraties voor verzenden/ontvangen. Test voordat je Syncthing naar een grote muziek- of documentbibliotheek laat verwijzen het aanmaken, hernoemen en verwijderen met wegwerpbestanden, en overweeg versiebeheer in Syncthing als herstel van onbedoelde verwijderingen op afstand belangrijk is.
Veelgestelde vragen over Syncthing op ZimaOS
Hebben latere gebruikers bevestigd dat de PUID/PGID-methode werkte?
Ja. Minstens twee latere deelnemers aan de bron vermeldden expliciet dat de beschreven methode hun probleem had opgelost.
Moet Syncthing als root worden uitgevoerd om toegang tot schijven te krijgen?
De huidige richtlijnen van IceWhale bevelen aan om de PUID/PGID van de echte ZimaOS-gebruiker en in plaats daarvan een geschikte submap te gebruiken.
Moet ik de doelmap eerst aanmaken in ZimaOS Bestanden?
In de huidige documentatie van IceWhale staat dat Syncthing de doelmap zelf moet aanmaken.
