Hoe de foutmelding ‘Docker permission denied’ op Ubuntu te verhelpen

De foutmelding Docker permission denied verschijnt meestal wanneer je gebruikersaccount geen rechten heeft om de Docker-daemon, de bijbehorende socket of vereiste bestanden en mappen te benaderen.

Docker hanteert deze beperkingen om ongeautoriseerde toegang te voorkomen, maar ze kunnen je workflow flink in de weg zitten wanneer je ontwikkelomgevingen op Ubuntu instelt.

Je lost de Docker permission denied fout op met de volgende zes bewezen oplossingen:

1. Gebruikersgroep aanpassen. Voeg je gebruikersaccount toe aan de docker-groep, zodat je Docker-commando’s kunt uitvoeren zonder sudo.
2. Eigendom van bestanden en mappen corrigeren. Pas het eigendom van configuratiebestanden en gemounte volumes aan, zodat de Docker-engine gegevens kan lezen en schrijven.
3. Socketrechten controleren. Controleer de permissies van de Docker Unix-socket om zeker te weten dat het communicatiekanaal niet wordt geblokkeerd.
4. Uitvoeringsrechten van scripts instellen. Zorg dat Dockerfile-commando’s en ENTRYPOINT-scripts uitvoerrechten hebben om opstartfouten van containers te voorkomen.
5. Hardwaretoegang instellen. Geef containers expliciet toegang tot specifieke apparaten, zoals USB-apparaten of GPU’s, om hardwaregerelateerde permissieproblemen op te lossen.
6. Docker-daemon herstarten. Herstart de Docker-service en je gebruikerssessie om alle wijzigingen in rechten en groepslidmaatschappen toe te passen.

Vereisten

Voordat je de Docker-fout ‘permission denied’ herstelt, moet je ervoor zorgen dat je Linux-systeem voldoet aan de vereisten voor het wijzigen van administratieve instellingen.

• Administratieve toegang. Je hebt sudo of root privileges nodig om gebruikersgroepen en bestandsrechten aan te passen.
• Verificatie van de gebruikersgroep. Controleer uw huidige groepslidmaatschappen door het commando groups $USER uit te voeren.

• Docker-installatie. Controleer of Docker is geïnstalleerd en draait door docker –version uit te voeren.

Hoewel deze instructies gericht zijn op Ubuntu, zijn ze ook van toepassing op de meeste Debian-gebaseerde distributies.

1. Voeg uw gebruiker toe aan de Docker-groep

De meest voorkomende oorzaak van de permissie geweigerde fout is dat je gebruikersaccount geen deel uitmaakt van de docker groep.

Standaard draait de Docker daemon als een root-owned service. Alleen gebruikers in de docker -groep kunnen ermee communiceren zonder sudo te gebruiken.

Om dit probleem op te lossen, voeg je je huidige gebruiker toe aan de docker groep:

sudo usermod -aG docker $USER

Dit commando werkt je gebruikersaccount bij door het toe te voegen (-a) aan de opgegeven groep (-G). Hierdoor krijgt je gebruiker toestemming om de Docker daemon socket te benaderen en Docker commando’s direct uit te voeren.

Om het nieuwe groepslidmaatschap toe te passen, log je uit en vervolgens weer in.

Nadat u opnieuw bent ingelogd, bevestigt u dat de wijziging is doorgevoerd:

id -nG

De uitvoer zou docker moeten bevatten in de lijst met groepen.

Als je meteen wilt testen zonder uit te loggen, voer dan uit:

nieuwgrp dok

Dit commando past de groepswijziging alleen toe op je huidige terminalsessie.

2. Problemen met bestands- en mapmachtigingen oplossen

Als het toevoegen van uw gebruiker aan de groep het probleem niet oplost, kunnen onjuiste rechten op configuratiebestanden of gemounte volumes de fout veroorzaken.

Docker heeft lees- en schrijftoegang nodig tot zijn configuratiebestanden, vooral config.json.

Controleer eerst de permissies van je lokale Docker-configuratiemap:

ls -l ~/.docker/

Als de uitvoer laat zien dat de bestanden eigendom zijn van root in plaats van uw gebruiker, verander dan het eigendom met het commando chown:

sudo chown -R "$USER":"$USER" "$HOME/.docker"

Dit commando verandert recursief het eigendom van de .docker map naar je huidige gebruiker.

Los vervolgens toestemmingsproblemen op met betrekking tot gemounte volumes. Wanneer je een hostmap in een container mounten, heeft de containergebruiker toestemming nodig om van die map te lezen of ernaar te schrijven.

Als je bijvoorbeeld een container draait met een volume mount:

docker run -v ~/data:/app/data ubuntu

Zorg ervoor dat de hostmap ~/data de juiste rechten heeft. Je kunt lees- en schrijftoegang verlenen aan de gebruiker (u) met het volgende chmod commando:

chmod u+rw ~/data

Dit garandeert dat de gebruiker die eigenaar is van de map voldoende rechten heeft om gegevens in het gemounte volume te beheren.

3. Docker socket permissies controleren

De Docker daemon communiceert via een Unix socket die zich bevindt in /var/run/docker.sock. Als deze socket onjuiste rechten heeft, kan de Docker-client geen commando’s naar de daemon sturen.

Controleer de huidige socketpermissies:

ls -l /var/run/docker.sock

Je zou uitvoer moeten zien zoals hieronder:

srw-rw---- 1 root docker 0 dec 18 10:00 /var/run/docker.sock

Deze uitvoer laat zien dat root eigenaar is van de socket en dat de docker groep lees- en schrijftoegang heeft. Als je deze uitvoer ziet en je gebruiker behoort tot de docker groep, dan is de socketconfiguratie correct.

Als de groep niet docker is of de permissies verschillen, verander ze dan niet handmatig door chmod 666 /var/run/docker.sock uit te voeren, vooral in productieomgevingen.

Dit commando creëert een serieus veiligheidsrisico doordat het alle systeemgebruikers toegang geeft tot de Docker daemon, wat effectief controle op root-niveau over de host geeft.

Vertrouw in plaats daarvan op groepslidmaatschap door je gebruiker toe te voegen aan de docker groep. De Docker-daemon stelt automatisch de juiste socket-rechten in bij het opstarten.

4. Dockerfile- of ENTRYPOINT-scriptrechten repareren

Een Docker permission denied error kan ook optreden in een container als het entrypoint script geen execute rechten heeft.

Dit probleem treedt vaak op wanneer je scripts verplaatst van een niet-Linux bestandssysteem, zoals Windows, naar de Docker build context. In deze gevallen kan de uitvoerbare bit verloren gaan.

Als dit gebeurt, start de container niet omdat het script dat is gedefinieerd in de ENTRYPOINT – of CMD -instructie niet kan worden uitgevoerd.

Om het probleem op te lossen, voegt u een RUN -instructie toe na de COPY -regel in uw Dockerfile. Dit geeft uitvoeringsrechten aan het script.

RUN chmod +x /usr/local/bin/entrypoint.sh

Dit garandeert dat het script uitvoerbaar blijft, ongeacht de rechten op de hostmachine. Je zult deze stap vaak nodig hebben bij het bouwen van aangepaste afbeeldingen die afhankelijk zijn van opstartscripts.

5. Apparaattoegang verlenen aan Docker-containers

Als een container moet communiceren met hardware-apparaten, zoals een USB-station, webcam of GPU, kun je een permission denied error zien voor een apparaatpad als /dev/ttyUSB0.

Standaard draaien containers geïsoleerd en hebben ze geen toegang tot hostapparaten. Om toegang toe te staan, geef je expliciet het apparaat door wanneer je de container start met de –device vlag:

docker run --device=/dev/ttyUSB0 mijn-image

Als de container bredere permissies nodig heeft maar geen volledige apparaattoegang, geef dan specifieke Linux mogelijkheden met de –cap-add vlag:

docker run --cap-add=SYS_ADMIN my-image

Deze aanpak volgt het principe van de minste privileges – alleen de mogelijkheden toekennen die de container echt nodig heeft. Algemene mogelijkheden zijn NET_ADMIN voor netwerkconfiguratie en SYS_PTRACE voor debuggen.

Als specifieke apparaten of mogelijkheden niet genoeg zijn, kun je de –privileged vlag gebruiken:

docker run --privileged my-image

Deze optie geeft de container volledige toegang tot alle hostapparaten en schakelt de meeste beveiligings-isolatiefuncties uit.

Containers die in deze modus worden gestart, kunnen root-level controle over het hostsysteem krijgen. Gebruik –privileged alleen in vertrouwde lokale ontwikkelomgevingen of als er geen veiligere alternatieven zijn.

Geef voor productiewerklasten altijd de voorkeur aan –device voor specifieke hardware of –cap-add voor specifieke mogelijkheden.

6. Start Docker opnieuw op en test uw opstelling

Herstart de Docker-service nadat je wijzigingen in gebruikersgroepen of toestemmingscorrecties hebt toegepast, zodat de daemon de bijgewerkte configuratie herkent.

Docker herstarten met systemctl:

sudo systemctl herstart docker

Nadat de service is herstart, controleer de fix door de standaard hello-world container uit te voeren zonder sudo te gebruiken:

docker run hello-world

Als de afbeelding met succes wordt gedownload en uitgevoerd en een welkomstbericht wordt weergegeven, heb je het toestemmingsprobleem opgelost.

Als de fout zich blijft voordoen, start dan het hele systeem opnieuw op om ervoor te zorgen dat alle groepslidmaatschappen en sessiewijzigingen van kracht worden:

sudo opnieuw opstarten

Wat moet je nu leren in Docker?

Nu je Docker-installatie werkt zonder toestemmingsfouten, ben je klaar om vol vertrouwen en veilig met containers te werken.

Omgevingsproblemen oplossen is een essentiële eerste stap in je Docker-leerpad. Hierdoor kun je je concentreren op het bouwen en implementeren van applicaties in plaats van op het oplossen van problemen met de instellingen.

Als volgende stap kun je je verdiepen in de belangrijkste Docker-concepten door onze volledige Docker-tutorial te lezen. Het behandelt imagebeheer, containerlevenscycli, Docker Compose, datapersistentie en containernetwerken.

Alle tutorials op deze website voldoen aan de strenge edactionele standaarden en waarden van Hostinger.