L'errore La cartella '/tv/' non è scrivibile dall'utente 'abc' ciò significa che Sonarr riesce a vedere la directory montata, ma il processo in esecuzione all'interno del container non dispone dell'autorizzazione per scrivervi. Lo stesso problema può verificarsi in Radarr come errore relativo alla cartella principale dei film.
Nel caso della IceWhale Community di luglio 2025, entrambe le applicazioni provenivano dall'App Store di ZimaOS e utilizzavano i valori predefiniti PUID=1000 e PGID=1000. Le cartelle multimediali dell'utente si trovavano su un pool di archiviazione RAID. Un membro del team IceWhale ha suggerito di impostare entrambi gli ID su 0, e l'autore originale ha confermato che in questo modo le cartelle diventavano scrivibili. Tuttavia, eseguire l'applicazione con ID equivalenti a root garantisce un accesso al file system molto più ampio del necessario. La documentazione attuale di LinuxServer.io consiglia invece di far corrispondere PUID/PGID al proprietario o al gruppo delle directory dell'host.
Cosa significa “La cartella non è scrivibile dall'utente abc”
Il pacchetto dell'App Store di ZimaOS nella discussione utilizzava container Sonarr e Radarr in stile LinuxServer. Queste immagini eseguono il processo dell'applicazione con un utente interno comunemente visualizzato come abc, mentre PUID e PGID mappare tale processo interno a ID numerici di utente e gruppo nel file system dell'host.
Se la directory dell'host appartiene a un UID/GID diverso e i relativi bit di autorizzazione non consentono al processo mappato di scrivervi, Sonarr o Radarr possono esplorare il montaggio, ma non possono creare, rinominare, spostare o importare file multimediali.
Le mappature originali dell'App Store di ZimaOS
Il post includeva schermate di configurazione separate per Radarr e Sonarr. Le applicazioni riuscivano a vedere i volumi host configurati, ma la creazione della cartella principale non andava a buon fine all'interno delle applicazioni.
Gli errori di Sonarr e Radarr
Sonarr ha restituito:
Impossibile aggiungere la cartella principale
La cartella '/tv/' non è scrivibile dall'utente 'abc'
Radarr mostrava il problema corrispondente per il percorso dei film:
La soluzione della community: PUID=0 e PGID=0
Un membro del team IceWhale ha risposto:
PUID=0
PGID=0
L’autore originale ha modificato entrambi i valori impostandoli su zero e ha riferito che il problema sembrava risolto. Questa è quindi la soluzione confermata per quella specifica configurazione dell’App Store di ZimaOS del luglio 2025.
Tuttavia, UID 0 e GID 0 sono identità root in Linux. Eseguire Sonarr o Radarr con questi ID può consentire all’applicazione di scrivere in posizioni molto oltre la libreria multimediale prevista, se tali percorsi sono montati nel container. Usali solo come soluzione diagnostica o alternativa di compatibilità quando comprendi i privilegi di accesso che concedono.
Correzione preferita: fai corrispondere PUID e PGID al proprietario dello spazio di archiviazione dell’host
La documentazione attuale di LinuxServer.io per Sonarr e Radarr spiega il design previsto: imposta PUID e PGID in base al proprietario dello spazio di archiviazione dell’host PUID e PGID a un utente/gruppo dell’host che sia già proprietario del volume mappato o disponga dell’accesso in scrittura.
Le indicazioni di LinuxServer affermano che i problemi di autorizzazione si verificano quando un volume dell’host è di proprietà di ID che non corrispondono agli ID forniti al container. Il modello consigliato è:
PUID=1000
PGID=1000
solo quando UID 1000 e GID 1000 sono effettivamente appropriati per i percorsi dei contenuti multimediali. Il numero 1000 non è intrinsecamente corretto; è semplicemente un ID comune per il primo utente Linux non root.
Consulta la documentazione di LinuxServer per Sonarr e la documentazione di LinuxServer per Radarr.
Come controllare il proprietario e i permessi dello spazio di archiviazione
Se l’interfaccia File di ZimaOS non mostra i valori numerici di proprietario/gruppo Linux necessari, controlla il percorso effettivo dell’host da un terminale autorizzato.
Prima identifica la directory reale dell’host associata a /tv oppure /moviesQuindi controllalo:
ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATH
L’output numerico ti aiuta a determinare quale UID e GID sono attualmente proprietari della directory. Non eseguire questi comandi sul percorso disponibile solo nel container /tv dal sistema host, a meno che quello non sia effettivamente il percorso dell’host.
Se l’account destinato alla gestione dei contenuti multimediali è disponibile sull’host, puoi controllarne gli ID con:
id USERNAME
Quindi imposta Sonarr/Radarr PUID e PGID agli ID che corrispondono al modello di accesso che hai scelto deliberatamente.
Non eseguire chown alla cieca su /tv all’interno del container
Un’altra risposta della community suggeriva:
sudo chown abc:abc /tv/
Questo consiglio è rischioso se copiato senza contesto. La proprietà di una directory montata tramite bind mount è rappresentata in ultima analisi da ID numerici sull’host. Il nome abc esiste nei container LinuxServer e potrebbe non corrispondere a un account significativo sull’host. La modifica ricorsiva della proprietà può inoltre influire inaspettatamente su un’intera libreria multimediale.
Prima di usare chown, conferma:
- il percorso esatto dell’host da modificare;
- l’UID e il GID desiderati sull’host;
- se altri servizi, come qBittorrent, SABnzbd, Jellyfin o gli utenti SMB, debbano accedere agli stessi file;
- se sia più appropriato usare un gruppo condiviso invece di modificare la proprietà.
Esegui il backup delle configurazioni importanti ed evita di modificare ricorsivamente i permessi finché non ne comprendi gli effetti.
Pianifica i permessi dei contenuti multimediali condivisi nell’intero stack ARR
Sonarr e Radarr raramente operano da soli. Un client di download crea prima i file, poi Sonarr o Radarr li importa, mentre Jellyfin potrebbe leggerne il risultato. Se ogni container usa ID e mount non correlati, un’applicazione può creare file che un’altra non è in grado di modificare.
Una progettazione più ordinata consiste nell’assegnare alle applicazioni un gruppo comune o una mappatura PUID/PGID compatibile per il dataset condiviso. LinuxServer raccomanda inoltre percorsi dei volumi ben pianificati, affinché i client di download e le applicazioni ARR possano usare hard link o spostamenti atomici quando appropriato.
Ad esempio, invece di trattare download e contenuti multimediali come mount isolati e non correlati, un unico albero di dati condiviso sull’host può rendere più semplice ragionare sui permessi e sulla coerenza dei percorsi:
/data
├── download
├── media
│ ├── film
│ └── tv
Il percorso esatto di ZimaOS dipende dal pool di archiviazione e non dovrebbe essere copiato alla cieca.
Quando è utile la soluzione alternativa degli ID root?
Impostare PUID/PGID su 0 può essere utile come breve test diagnostico:
- Se l’errore scompare immediatamente, probabilmente il mount del container è corretto.
- Il problema rimanente è quindi probabilmente legato alla proprietà o alla mappatura dei permessi sull’host.
Una volta confermato, l’obiettivo più sicuro a lungo termine è assegnare al container solo i permessi necessari per i relativi percorsi multimediali e di download. Se il modello di archiviazione specifico di ZimaOS rende impraticabile una mappatura non root, documenta il motivo per cui sono necessari gli ID root e limita attentamente le directory montate.
Riavvia le app dopo aver modificato PUID o PGID
PUID e PGID vengono applicati all’avvio del container. Dopo averli modificati in ZimaOS:
- Salva la configurazione dell’app.
- Riavvia o ricrea il container di Sonarr/Radarr tramite ZimaOS.
- Apri nuovamente le impostazioni della cartella principale.
- Prova a creare o selezionare la cartella mappata.
Se la cartella rimane non scrivibile, confronta la proprietà numerica e la modalità della directory sull’host con gli ID attualmente utilizzati dal container.
Checklist delle autorizzazioni di Sonarr/Radarr su ZimaOS
- Conferma che il percorso dei media sull’host sia montato in Sonarr o Radarr.
- Conferma che il percorso del container sia quello selezionato all’interno dell’app.
- Esamina l’UID, il GID e i bit delle autorizzazioni del percorso sull’host.
- Controlla l’attuale
PUIDePGIDnelle impostazioni dell’app ZimaOS. - Preferisci gli ID che corrispondono al proprietario/gruppo previsto sull’host.
- Riavvia il container dopo aver modificato gli ID.
- Usa PUID/PGID 0 solo comprendendo l’accesso a livello root che concedono.
- Evita operazioni ricorsive troppo ampie
chmod 777o usare alla ciecachowncorrezioni. - Assicurati che i client di download e i server multimediali utilizzino un modello compatibile di autorizzazioni condivise.
FAQ sulle autorizzazioni di Sonarr e Radarr
Chi è l’utente abc?
abc è il nome dell’utente del servizio interno comunemente usato dai container LinuxServer.io. PUID e PGID determinano l’identità numerica dell’host utilizzata dal processo per accedere ai volumi mappati.
Perché PUID=1000 e PGID=1000 non funzionano?
Questi valori funzionano solo quando l’UID/GID 1000 dispone dell’accesso necessario alla cartella dei media sull’host. Se la directory RAID di ZimaOS appartiene a un altro utente o gruppo, il container potrebbe riuscire a visualizzarla ma non a scriverci.
PUID=0 e PGID=0 risolvono il problema?
Ha risolto il problema del caso originale della community, come confermato dall’autore. Tuttavia, concede anche un accesso equivalente a quello di root all’interno del filesystem mappato, quindi non dovrebbe essere automaticamente la configurazione permanente preferita.
Devo eseguire chmod 777 sulla cartella dei media?
No, non come soluzione predefinita. Le autorizzazioni di scrittura per tutti sono inutilmente ampie e possono nascondere il vero problema di mancata corrispondenza della proprietà. Configura invece deliberatamente l’identità del container e le autorizzazioni del gruppo condiviso.
Sonarr, Radarr e il client di download devono usare lo stesso PUID/PGID?
Non devono sempre usare ID utente identici, ma devono adottare un modello compatibile di proprietà e gruppi per tutti i file e le cartelle condivisi. Usare un gruppo condiviso coerente è un metodo comune per evitare errori di importazione e ridenominazione.
