Åtgärda felen ”Mappen är inte skrivbar” i Sonarr och Radarr på ZimaOS

Felet Mappen '/tv/' är inte skrivbar för användaren 'abc' det innebär att Sonarr kan se den monterade katalogen, men att processen som körs inuti containern inte har behörighet att skriva till den. Samma problem kan uppstå i Radarr som ett fel för filmens rotmapp.

I IceWhale Community-fallet från juli 2025 kom båda programmen från ZimaOS App Store och använde standardvärdet PUID=1000 och PGID=1000. Användarens mediemappar låg på en RAID-lagringspool. En medlem i IceWhale-teamet föreslog att båda ID:na skulle ställas in på 0, och den ursprungliga skribenten bekräftade att detta gjorde mapparna skrivbara. Det är ett viktigt resultat från källan, men att köra programmet med root-likvärdiga ID:n ger betydligt bredare åtkomst till filsystemet än vad som normalt behövs. Aktuell dokumentation från LinuxServer.io rekommenderar i stället att PUID/PGID matchar ägaren eller gruppen för värdkatalogerna.

Vad ”Mappen är inte skrivbar för användaren abc” betyder

ZimaOS App Store-paketet i tråden använde Sonarr- och Radarr-containrar av LinuxServer-typ. Dessa avbildningar kör programprocessen som en intern användare som vanligtvis visas som abc, medan PUID och PGID mappa den interna processen till numeriska användar- och grupp-ID:n i värdfilsystemet.

Om värdkatalogen tillhör ett annat UID/GID och dess behörighetsbitar inte tillåter den mappade processen att skriva, kan Sonarr eller Radarr bläddra i monteringen men inte skapa, byta namn på, flytta eller importera media där.

De ursprungliga mappningarna i ZimaOS App Store

Inlägget innehöll separata konfigurationsskärmbilder för Radarr och Sonarr. Programmen kunde se de konfigurerade värdvolymerna, men det gick inte att skapa rotmappar i programmen.

Sonarr- och Radarr-felen

Sonarr returnerade:

Det gick inte att lägga till rotmappen
Mappen '/tv/' är inte skrivbar för användaren 'abc'

Radarr visade motsvarande problem för filmsökvägen:

Community-lösningen: PUID=0 och PGID=0

En medlem av IceWhale-teamet svarade:

PUID=0
PGID=0

Den ursprungliga skribenten ändrade båda värdena till noll och rapporterade att problemet verkade vara löst. Detta är därför den bekräftade lösningen för just den ZimaOS App Store-konfigurationen från juli 2025.

UID 0 och GID 0 är däremot root-identiteter på Linux. Om du kör Sonarr eller Radarr med dessa ID:n kan programmet få möjlighet att skriva till platser långt utanför det avsedda mediebiblioteket, om dessa sökvägar är monterade i containern. Använd detta endast som en diagnostisk lösning eller kompatibilitetslösning när du förstår vilka åtkomster det ger.

Rekommenderad lösning: Matcha PUID och PGID med lagringsägaren på värddatorn

Den aktuella dokumentationen från LinuxServer.io för Sonarr och Radarr förklarar den avsedda utformningen: ange PUID och PGID så att de matchar ägarskapet för lagringen på värddatorn. PUID och PGID till en värdanvändare/-grupp som redan äger den mappade volymen eller har skrivbehörighet till den.

LinuxServers vägledning säger att behörighetsproblem uppstår när en värdvolym ägs av ID:n som inte matchar de ID:n som anges för containern. Deras rekommenderade mönster är:

PUID=1000
PGID=1000

endast när UID 1000 och GID 1000 faktiskt är lämpliga för mediesökvägarna. Numret 1000 är inte automatiskt korrekt; det är helt enkelt ett vanligt första användar-ID för en icke-root-användare i Linux.

Se den aktuella LinuxServer-dokumentationen för Sonarr och LinuxServer-dokumentationen för Radarr.

Så kontrollerar du lagringsägare och behörigheter

Om ZimaOS filgränssnitt inte visar de numeriska Linux-värdena för ägare/grupp som du behöver, kan du inspektera den faktiska värdsökvägen från en auktoriserad terminal.

Identifiera först den riktiga värddatorskatalogen som är mappad till /tv eller /moviesInspektera den sedan:

ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATH

Den numeriska utskriften hjälper dig att avgöra vilket UID och GID som för närvarande äger katalogen. Kör inte dessa kommandon mot den sökväg som endast finns i containern. /tv från värddatorn, om det inte verkligen är värddatorns sökväg.

Om det avsedda kontot för mediehantering finns tillgängligt på värden kan du kontrollera dess ID:n med:

id USERNAME

Ställ sedan in Sonarr/Radarr PUID och PGID till de ID:n som motsvarar den åtkomstmodell du avsiktligt vill använda.

Ändra inte ägarskapet för /tv blint inuti containern

Ett annat svar i communityt föreslog:

sudo chown abc:abc /tv/

Det rådet är riskabelt att kopiera utan sammanhang. Ägarskapet för en bindmonterad katalog representeras i slutändan av numeriska ID:n på värden. Namnet abc finns i LinuxServer-containrar och kanske inte finns som ett meningsfullt värdkonto. Att ändra ägarskap rekursivt kan också oväntat påverka ett helt mediebibliotek.

Innan du använder chown, bekräfta:

• den exakta värdsökväg som ändras;
• det önskade UID:t och GID:t på värden;
• om andra tjänster, till exempel qBittorrent, SABnzbd, Jellyfin eller SMB-användare, behöver åtkomst till samma filer;
• om en gemensam grupp är lämpligare än att ändra ägarskapet.

Säkerhetskopiera viktig konfiguration och undvik rekursiva behörighetsändringar tills du förstår deras effekt.

Planera delade mediebehörigheter för hela ARR-stacken

Sonarr och Radarr arbetar sällan ensamma. En nedladdningsklient skapar först filerna, därefter importerar Sonarr eller Radarr dem, och Jellyfin kan sedan läsa resultatet. Om varje container använder separata ID:n och monteringar kan ett program skapa filer som ett annat program inte kan ändra.

En renare design är att ge programmen en gemensam grupp eller kompatibel PUID/PGID-mappning för den delade datamängden. LinuxServer rekommenderar också välplanerade volymsökvägar så att nedladdningsklienter och ARR-program kan använda hårdlänkar eller atomiska flyttar där det är lämpligt.

Till exempel kan ett enda gemensamt dataträd på värden göra det enklare att förstå behörigheter och sökvägskonsekvens, i stället för att behandla nedladdningar och media som separata, isolerade monteringar:

/data
├── nedladdningar
├── media
│   ├── filmer
│   └── tv

Den exakta ZimaOS-sökvägen beror på din lagringspool och bör inte kopieras blint.

När är root-ID-lösningen användbar?

Ställ in PUID/PGID på 0 kan vara användbart som en kort diagnostisk åtgärd:

• Om felet försvinner omedelbart är själva containermonteringen troligen korrekt.
• Det återstående problemet beror då troligen på ägarskap på värden eller behörighetsmappning.

När detta har bekräftats är det säkrare långsiktiga målet att ge containern endast de behörigheter som behövs för dess medie- och nedladdningssökvägar. Om just din ZimaOS-lagringsmodell gör en mappning utan root opraktisk bör du dokumentera varför root-ID:n krävs och begränsa de monterade katalogerna noggrant.

Starta om apparna efter att du har ändrat PUID eller PGID

PUID och PGID tillämpas när containern startar. När du har ändrat dem i ZimaOS:

1. Spara appkonfigurationen.
2. Starta om eller återskapa Sonarr/Radarr-containern via ZimaOS.
3. Öppna inställningarna för rotmappen igen.
4. Testa att skapa eller välja den mappade mappen.

Om mappen fortfarande inte är skrivbar jämför du den numeriska ägaren och behörighetsläget för katalogen på värden med de ID:n som containern nu använder.

Checklista för Sonarr/Radarr-behörigheter i ZimaOS

1. Bekräfta att mediesökvägen på värden är monterad i Sonarr eller Radarr.
2. Bekräfta att containersökvägen är den som väljs i appen.
3. Kontrollera värdens sökvägs UID, GID och behörighetsbitar.
4. Kontrollera det aktuella PUID och PGID i ZimaOS appinställningar.
5. Föredra ID:n som matchar den avsedda ägaren och gruppen på värden.
6. Starta om containern efter att du har ändrat ID:n.
7. Använd PUID/PGID 0 endast om du förstår vilken åtkomst på root-nivå det ger.
8. Undvik omfattande rekursiva chmod 777 eller blint chown korrigeringar.
9. Se till att nedladdningsklienter och medieservrar använder en kompatibel modell för delade behörigheter.

Vanliga frågor om behörigheter i Sonarr och Radarr

Vem är användaren abc?

abc är det interna tjänstanvändarnamnet som ofta används av LinuxServer.io-containrar. PUID och PGID avgör vilken numerisk identitet på värden som processen använder för åtkomst till mappade volymer.

Varför fungerar inte PUID=1000 och PGID=1000?

Dessa värden fungerar endast när UID/GID 1000 har den åtkomst som krävs till mediekatalogen på värden. Om din RAID-katalog i ZimaOS tillhör en annan användare eller grupp kan containern kanske se den men inte skriva till den.

Löser PUID=0 och PGID=0 problemet?

Det löste det ursprungliga fallet i communityt, vilket bekräftades av författaren. Det ger också root-motsvarande åtkomst till det mappade filsystemet, så det bör inte automatiskt vara den föredragna permanenta konfigurationen.

Bör jag köra chmod 777 på mediemappen?

Nej, inte som standardlösning. Skrivbehörighet för alla är onödigt omfattande och kan dölja den faktiska ägarmissmatchningen. Matcha i stället containerns identitet och den delade gruppens behörigheter på ett genomtänkt sätt.

Bör Sonarr, Radarr och nedladdningsklienten använda samma PUID/PGID?

De behöver inte alltid ha identiska användar-ID:n, men de behöver en kompatibel ägar- och gruppmodell för alla filer och mappar som de delar. Att använda en konsekvent delad grupp är ett vanligt sätt att undvika import- och namnbytesfel.