Feb 13, 2026
Faradilla A.
5min di lettura
L’errore “permission denied” di Docker si verifica di solito quando il tuo account utente non dispone dei permessi necessari per accedere al socket del daemon Docker o ai file e alle directory richiesti.
Docker utilizza queste restrizioni per impedire accessi non autorizzati, ma possono interrompere il flusso di lavoro, soprattutto quando configuri ambienti di sviluppo su Ubuntu.
Per risolvere l’errore “permission denied” di Docker, segui queste sei soluzioni collaudate:
Prima di correggere l’errore “permission denied” di Docker, assicurati che il tuo sistema Linux soddisfi i requisiti necessari per modificare le impostazioni amministrative:


Sebbene queste istruzioni siano incentrate su Ubuntu, si applicano alla maggior parte delle distribuzioni basate su Debian.
La causa più comune dell’errore “permission denied” è che il tuo account utente non fa parte del gruppo docker.
Per impostazione predefinita, il daemon Docker viene eseguito come servizio di proprietà dell’utente root. Solo gli utenti appartenenti al gruppo docker possono comunicare con esso senza utilizzare sudo.
Per risolvere il problema, aggiungi il tuo utente corrente al gruppo docker:
sudo usermod -aG docker $USER
Questo comando aggiorna il tuo account utente aggiungendolo (-a) al gruppo specificato (-G). In questo modo, il tuo utente ottiene i permessi per accedere al socket del daemon Docker ed eseguire direttamente i comandi Docker.
Per applicare la nuova appartenenza al gruppo, esci e accedi nuovamente.
Dopo aver effettuato l’accesso, verifica che la modifica abbia avuto effetto eseguendo:
id -nG
L’output dovrebbe includere docker nell’elenco dei gruppi.

Se desideri verificare subito la modifica senza disconnetterti, esegui:
newgrp docker
Questo comando applica il cambio di gruppo solo alla sessione di terminale corrente.
Se aggiungere il tuo utente al gruppo non risolve il problema, permessi errati sui file di configurazione o sui volumi montati potrebbero causare l’errore.
Docker necessita di accesso in lettura e scrittura ai file di configurazione, in particolare al file config.json.
Per prima cosa, verifica i permessi della directory di configurazione Docker locale:
ls -l ~/.docker/

Se l’output mostra che i file appartengono a root invece che al tuo utente, modifica la proprietà con il comando chown:
sudo chown -R "$USER":"$USER" "$HOME/.docker"
Questo comando modifica ricorsivamente la proprietà della directory .docker, assegnandola al tuo utente corrente.
Poi, risolvi eventuali problemi relativi ai volumi montati. Quando monti una directory dell’host in un container, l’utente del container deve avere i permessi necessari per leggere o scrivere in quella directory.
Ad esempio:
docker run -v ~/data:/app/data ubuntu
Verifica che la directory dell’host ~/data abbia i permessi corretti. Puoi concedere all’utente proprietario (u) i permessi di lettura e scrittura con:
chmod u+rw ~/data
In questo modo garantisci che l’utente proprietario della directory possa gestire correttamente i dati all’interno del volume montato.
Il daemon Docker comunica tramite un socket Unix situato in /var/run/docker.sock. Se questo socket ha permessi errati, il client Docker non può inviare comandi al daemon.
Verifica i permessi correnti:
ls -l /var/run/docker.sock
Dovresti vedere un output simile al seguente:
srw-rw---- 1 root docker 0 Dec 18 10:00 /var/run/docker.sock
Questo indica che root è proprietario del socket e che il gruppo docker dispone dei permessi di lettura e scrittura. Se il tuo utente appartiene al gruppo docker, la configurazione è corretta.

Se il gruppo non è docker o i permessi sono diversi, non modificare manualmente i permessi eseguendo chmod 666 /var/run/docker.sock, soprattutto negli ambienti di produzione.
Questo comando rappresenta un grave rischio per la sicurezza, poiché concede a tutti gli utenti del sistema accesso al daemon Docker, equivalendo di fatto a un controllo di livello root sull’host.
Affidati invece all’appartenenza al gruppo docker. Il daemon imposterà automaticamente le autorizzazioni corrette del socket all’avvio.
Un errore “permission denied” può verificarsi anche all’interno di un container quando lo script ENTRYPOINT non dispone dei permessi di esecuzione.
Questo problema è comune quando si spostano script da un file system non Linux, come Windows, nel contesto di build Docker. In questi casi, il bit di esecuzione può andare perso.
Il container non riesce quindi ad avviarsi perché non può eseguire lo script definito nell’istruzione ENTRYPOINT o CMD.
Per risolvere il problema, aggiungi un’istruzione RUN dopo la riga COPY nel tuo Dockerfile. In questo modo concedi i permessi di esecuzione allo script:
RUN chmod +x /usr/local/bin/entrypoint.sh

Questo garantisce che lo script rimanga eseguibile, indipendentemente dai permessi sulla macchina host. Ti servirà spesso questo passaggio quando crei immagini personalizzate che dipendono da script di avvio.
Se un container deve interagire con dispositivi hardware, come un’unità USB, una webcam o una GPU, potresti riscontrare un errore “permission denied” per un percorso del dispositivo come /dev/ttyUSB0.
Per impostazione predefinita, i container vengono eseguiti in isolamento e non possono accedere ai dispositivi dell’host. Per consentire l’accesso, passa esplicitamente il dispositivo quando avvii il container utilizzando il flag –device:
docker run --device=/dev/ttyUSB0 my-image
Se il container ha bisogno di permessi più ampi ma non dell’accesso completo ai dispositivi, puoi concedere specifiche capacità Linux con il flag –cap-add:
docker run --cap-add=SYS_ADMIN my-image
Questo approccio segue il principio del privilegio minimo – concedendo solo le capacità di cui il container ha effettivamente bisogno. Le capacità comuni includono NET_ADMIN per la configurazione di rete e SYS_PTRACE per il debug.
Quando dispositivi o capacità specifiche non sono sufficienti, puoi usare il flag –privileged:
docker run --privileged my-image

Questa opzione concede al container l’accesso completo a tutti i dispositivi dell’host e disabilita la maggior parte delle funzionalità di isolamento della sicurezza.
I container avviati in questa modalità possono ottenere il controllo a livello root sul sistema host. Usa –privileged solo in ambienti di sviluppo locali affidabili o quando non sono disponibili alternative più sicure.
Per i carichi di lavoro di produzione, preferisci sempre –device per hardware specifico o –cap-add per capacità specifiche.
Dopo aver applicato le modifiche ai gruppi utente o le correzioni dei permessi, riavvia il servizio Docker affinché il daemon riconosca la configurazione aggiornata.
Riavvia Docker con systemctl:
sudo systemctl restart docker
Dopo il riavvio del servizio, verifica la correzione eseguendo il container hello-world standard senza usare sudo:
docker run hello-world
Se l’immagine viene scaricata ed eseguita correttamente mostrando un messaggio di benvenuto, l’errore di permessi è risolto.

Se l’errore persiste, riavvia l’intero sistema per assicurarti che tutte le appartenenze ai gruppi e le modifiche alla sessione abbiano effetto:
sudo reboot
Ora che la tua installazione di Docker funziona senza errori di autorizzazione, sei pronto a lavorare con i container in modo sicuro e con maggiore sicurezza.
Risolvere i problemi legati all’ambiente è un passo fondamentale nel tuo percorso di apprendimento di Docker. Ti permette di concentrarti sullo sviluppo e sulla distribuzione delle applicazioni, invece di dover risolvere continuamente problemi di configurazione.
Come passo successivo, approfondisci la comprensione dei concetti chiave di Docker, come la gestione delle immagini, i cicli di vita dei container, Docker Compose, la persistenza dei dati e il networking dei container.
Tutti i contenuti dei tutorial presenti su questo sito web sono soggetti ai rigorosi standard editoriali e ai valori di Hostinger.