De foutmelding Map '/tv/' is niet schrijfbaar voor gebruiker 'abc' dit betekent dat Sonarr de gekoppelde directory kan zien, maar dat het proces in de container geen toestemming heeft om erin te schrijven. Hetzelfde probleem kan zich in Radarr voordoen als fout bij de hoofdmap voor films.
In de IceWhale Community-zaak van juli 2025 kwamen beide toepassingen uit de ZimaOS App Store en gebruikten ze de standaard PUID=1000 en PGID=1000. De mediamappen van de gebruiker stonden op een RAID-opslagpool. Een teamlid van IceWhale stelde voor om beide ID's in te stellen op 0, en de oorspronkelijke poster bevestigde dat dit de mappen schrijfbaar maakte. Dat is een belangrijk resultaat uit de bron, maar de toepassing uitvoeren met ID's die gelijkwaardig zijn aan root geeft veel ruimere toegang tot het bestandssysteem dan normaal nodig is. De huidige documentatie van LinuxServer.io raadt in plaats daarvan aan om PUID/PGID af te stemmen op de eigenaar of groep van de hostdirectories.
Wat betekent 'Map is niet schrijfbaar voor gebruiker abc'?
Het ZimaOS App Store-pakket in de thread gebruikte LinuxServer-achtige Sonarr- en Radarr-containers. Deze images voeren het toepassingsproces uit als een interne gebruiker die doorgaans wordt weergegeven als abc, terwijl PUID en PGID koppel dat interne proces aan numerieke gebruikers- en groeps-ID's op het hostbestandssysteem.
Als de hostdirectory van een andere UID/GID is en de machtigingsbits het gekoppelde proces niet toestaan om te schrijven, kunnen Sonarr of Radarr de koppeling doorzoeken, maar daar geen media aanmaken, hernoemen, verplaatsen of importeren.
De oorspronkelijke ZimaOS App Store-koppelingen
Het bericht bevatte afzonderlijke configuratieschermafbeeldingen voor Radarr en Sonarr. De toepassingen konden de geconfigureerde hostvolumes zien, maar het aanmaken van hoofdmapmappen mislukte binnen de toepassingen.
De fouten in Sonarr en Radarr
Sonarr gaf het volgende terug:
Kan hoofdmap niet toevoegen
Map '/tv/' is niet schrijfbaar voor gebruiker 'abc'
Radarr gaf het overeenkomstige probleem voor het filmpad weer:
De communityoplossing: PUID=0 en PGID=0
Een teamlid van IceWhale antwoordde:
PUID=0
PGID=0De oorspronkelijke poster wijzigde beide waarden in nul en meldde dat het probleem daarmee opgelost leek. Dit is daarom de bevestigde oplossing voor die specifieke ZimaOS App Store-configuratie uit juli 2025.
UID 0 en GID 0 zijn echter root-identiteiten in Linux. Als je Sonarr of Radarr met deze ID's uitvoert, kan de toepassing schrijven naar locaties ver buiten de bedoelde mediabibliotheek als die paden in de container zijn gekoppeld. Gebruik dit alleen als diagnostische of compatibiliteitsoplossing wanneer je begrijpt welke toegang dit verleent.
Aanbevolen oplossing: PUID en PGID laten overeenkomen met de eigenaar van de hostopslag
De huidige documentatie van LinuxServer.io voor Sonarr en Radarr legt het beoogde ontwerp uit: stel PUID en PGID in op de eigenaar van de hostopslag. PUID en PGID aan een hostgebruiker of -groep die al eigenaar is van het gekoppelde volume of daar schrijftoegang toe heeft.
Volgens de richtlijnen van LinuxServer ontstaan machtigingsproblemen wanneer een hostvolume eigendom is van ID's die niet overeenkomen met de ID's die aan de container zijn doorgegeven. Hun aanbevolen patroon is:
PUID=1000
PGID=1000alleen wanneer UID 1000 en GID 1000 daadwerkelijk geschikt zijn voor de mediapaden. Het getal 1000 is niet inherent correct; het is gewoon een veelgebruikte eerste niet-root Linux-gebruikers-ID.
Bekijk de actuele LinuxServer Sonarr-documentatie en LinuxServer Radarr-documentatie.
Opslageigenaar en -machtigingen inspecteren
Als de Bestanden-interface van ZimaOS niet de numerieke Linux-eigenaars- en groepswaarden toont die je nodig hebt, inspecteer dan het daadwerkelijke hostpad vanuit een geautoriseerde terminal.
Identificeer eerst de echte hostmap die is gekoppeld aan /tv of /moviesInspecteer deze vervolgens:
ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATHDe numerieke uitvoer helpt je bepalen welke UID en GID momenteel eigenaar zijn van de map. Voer deze opdrachten niet uit op het pad dat alleen in de container bestaat. /tv van de host, tenzij dat daadwerkelijk het hostpad is.
Als het account voor mediabeheer dat je bedoelt op de host beschikbaar is, kun je de ID's ervan bekijken met:
id USERNAMEStel vervolgens de Sonarr/Radarr PUID en PGID naar de ID's die overeenkomen met het toegangsmodel dat je bewust wilt gebruiken.
Voer niet blind chown /tv uit in de container
Een andere reactie uit de community stelde voor:
sudo chown abc:abc /tv/Dat advies is riskant wanneer het zonder context wordt overgenomen. Het eigenaarschap van een aan de host gekoppelde map wordt uiteindelijk op de host door numerieke ID's weergegeven. De naam abc bestaat in LinuxServer-containers en mogelijk niet overeenkomt met een betekenisvol hostaccount. Het recursief wijzigen van het eigenaarschap kan ook onverwacht een volledige mediabibliotheek beïnvloeden.
Voordat je chown, controleer:
- het exacte hostpad dat wordt gewijzigd;
- de gewenste UID en GID op de host;
- of andere services zoals qBittorrent, SABnzbd, Jellyfin of SMB-gebruikers toegang tot dezelfde bestanden nodig hebben;
- of een gedeelde groep geschikter is dan het wijzigen van het eigenaarschap.
Maak een back-up van belangrijke configuratie en vermijd recursieve wijzigingen van rechten totdat je begrijpt wat het effect ervan is.
Plan gedeelde mediamachtigingen voor de volledige ARR-stack
Sonarr en Radarr werken zelden alleen. Een downloadclient maakt eerst bestanden aan, waarna Sonarr of Radarr ze importeert en Jellyfin het resultaat mogelijk leest. Als elke container niet-gerelateerde ID's en mounts gebruikt, kan de ene toepassing bestanden aanmaken die een andere toepassing niet kan wijzigen.
Een netter ontwerp is om de toepassingen een gemeenschappelijke groep of compatibele PUID/PGID-mapping voor de gedeelde dataset te geven. LinuxServer raadt ook goed geplande volumepaden aan, zodat downloadclients en ARR-toepassingen waar passend hardlinks of atomaire verplaatsingen kunnen gebruiken.
In plaats van downloads en media als losstaande, geïsoleerde mounts te behandelen, kan één gedeelde gegevensstructuur op de host het gemakkelijker maken om rechten en padconsistentie te overzien:
/data
├── downloads
├── media
│ ├── films
│ └── tvHet exacte ZimaOS-pad hangt af van je opslagpool en mag niet blind worden gekopieerd.
Wanneer is de root-ID-omweg nuttig?
PUID/PGID instellen op 0 kan nuttig zijn als korte diagnose:
- Als de fout onmiddellijk verdwijnt, is de containermount zelf waarschijnlijk correct.
- Het resterende probleem ligt dan waarschijnlijk bij het eigenaarschap op de host of de rechtenmapping.
Zodra dit is bevestigd, is het op de lange termijn veiliger om de container alleen de benodigde rechten voor de media- en downloadpaden te geven. Als je door het specifieke ZimaOS-opslagmodel geen niet-rootkoppeling kunt gebruiken, leg dan vast waarom root-ID's vereist zijn en beperk de gekoppelde mappen zorgvuldig.
Start de apps opnieuw nadat je PUID of PGID hebt gewijzigd
PUID en PGID worden toegepast wanneer de container start. Nadat je ze in ZimaOS hebt gewijzigd:
- Sla de appconfiguratie op.
- Start de Sonarr-/Radarr-container opnieuw of maak deze opnieuw aan via ZimaOS.
- Open de instellingen voor de hoofdmap opnieuw.
- Test of je de gekoppelde map kunt aanmaken of selecteren.
Als de map niet beschrijfbaar blijft, vergelijk dan het numerieke eigendom en de modus van de map op de host met de ID's die de container nu gebruikt.
ZimaOS-checklist voor Sonarr-/Radarr-machtigingen
- Bevestig dat het mediapad op de host in Sonarr of Radarr is gekoppeld.
- Bevestig dat het containerpad het pad is dat in de app wordt geselecteerd.
- Controleer de UID, GID en machtigingsbits van het pad op de host.
- Controleer de huidige
PUIDenPGIDin de ZimaOS-appinstellingen. - Geef de voorkeur aan ID's die overeenkomen met de beoogde eigenaar/groep op de host.
- Start de container opnieuw nadat je de ID's hebt gewijzigd.
- Gebruik PUID/PGID 0 alleen als je begrijpt welke toegang op rootniveau dit verleent.
- Vermijd brede recursieve
chmod 777of blindelingschownoplossingen. - Zorg ervoor dat downloadclients en mediaservers een compatibel model voor gedeelde machtigingen gebruiken.
Veelgestelde vragen over Sonarr- en Radarr-machtigingen
Wie is gebruiker abc?
abc is de interne servic gebruikersnaam die vaak wordt gebruikt door LinuxServer.io-containers. PUID en PGID bepalen welke numerieke identiteit op de host het proces gebruikt voor toegang tot gekoppelde volumes.
Waarom werken PUID=1000 en PGID=1000 niet?
Deze waarden werken alleen wanneer UID/GID 1000 de vereiste toegang tot de mediamap op de host heeft. Als je ZimaOS RAID-map eigendom is van een andere gebruiker of groep, kan de container deze mogelijk wel zien maar er niet naar schrijven.
Lost PUID=0 en PGID=0 het probleem op?
Het loste de oorspronkelijke communitycasus op, zoals de auteur bevestigde. Het verleent echter ook root-equivalente toegang binnen het gekoppelde bestandssysteem, dus dit zou niet automatisch de voorkeursconfiguratie voor de lange termijn moeten zijn.
Moet ik chmod 777 op de mediamap uitvoeren?
Niet als standaardoplossing. Wereldwijd schrijfbare machtigingen zijn onnodig ruim en kunnen de daadwerkelijke mismatch in eigendom verbergen. Stem in plaats daarvan bewust de containeridentiteit en de machtigingen van de gedeelde groep op elkaar af.
Moeten Sonarr, Radarr en de downloadclient dezelfde PUID/PGID gebruiken?
Ze hebben niet altijd identieke gebruikers-ID's nodig, maar wel een compatibel eigendoms-/groepsmodel voor bestanden en mappen die ze delen. Een consistente gedeelde groep is een veelgebruikte manier om import- en hernoemingsfouten te voorkomen.
