‘Permission denied’ of EACCES op Linux? Zo lees je rechten met ls -l en stat en zet je eigenaar en rechten veilig goed met chown en chmod. Met stappen.
Permission denied (in programma’s vaak EACCES, foutnummer 13) betekent dat de gebruiker waaronder een programma draait iets niet mag: een bestand lezen of schrijven, een map openen of een script uitvoeren. Linux kijkt daarvoor naar de eigenaar, de groep en de rechten van het bestand én van elke map in het pad erboven.
Rechten bestaan uit drie letters per doelgroep (eigenaar, groep, overige): r lezen, w schrijven en x uitvoeren. Bij een map betekent x dat je de map in mag. In getallen: 4 lezen, 2 schrijven, 1 uitvoeren, opgeteld per doelgroep. Dus 644 is eigenaar lezen en schrijven, de rest alleen lezen; 755 geeft de eigenaar alles en de rest lezen en openen.
Op webservers ontstaat de fout vaak doordat bestanden als root of als een andere gebruiker zijn geüpload, terwijl de webserver of PHP onder een eigen gebruiker draait, zoals www-data op Debian en Ubuntu. Verwant is Operation not permitted (EPERM): dan is het niet een kwestie van rechten op het bestand, maar mag de handeling helemaal niet, bijvoorbeeld omdat alleen root hem mag uitvoeren of het bestand onveranderbaar is gemaakt.
sudo werkt het wel en zonder niet: het is een rechtenkwestie, geen ontbrekend bestand.(13: Permission denied), dan hoort die bij 403 Forbidden.npm install -g is het een specifiek geval: zie npm EACCES.Menunamen kunnen per versie of toestel iets anders heten. Loop de stappen op volgorde af en stop zodra het werkt.
Bekijk wie de eigenaar is en welke rechten er gelden. ls -l toont rechten, eigenaar en groep; stat geeft dezelfde informatie met de rechten ook als getal. Controleer met id onder welke gebruiker en in welke groepen jij of de dienst draait.
ls -l /var/www/voorbeeld/config.php
stat /var/www/voorbeeld/config.php
id
ps -eo user,comm | grep -E 'nginx|apache2|httpd|php-fpm' | sort -uOok als het bestand zelf goed staat, moet de gebruiker elke bovenliggende map kunnen openen (de x-bit). namei -l toont de rechten van elke stap. Test daarna met sudo -u of de webservergebruiker het bestand echt kan lezen.
namei -l /var/www/voorbeeld/public/index.php
sudo -u www-data cat /var/www/voorbeeld/public/index.php > /dev/null && echo leesbaarGeef bestanden een eigenaar die past bij wie ze beheert. Een veelgebruikte opzet: een eigen gebruiker voor het beheer als eigenaar, met de groep van de webserver, zodat die kan lezen. Alleen mappen waarin de applicatie echt moet schrijven (uploads, cache) krijgen schrijfrechten voor de webserver.
sudo chown -R beheerder:www-data /var/www/voorbeeld
sudo chown -R www-data:www-data /var/www/voorbeeld/storage /var/www/voorbeeld/uploadsGangbaar is 644 voor bestanden en 755 voor mappen. Doe dat apart voor bestanden en mappen met find, zodat bestanden niet onbedoeld uitvoerbaar worden. Configuratiebestanden met wachtwoorden kunnen strenger, bijvoorbeeld 640 met de webservergroep.
find /var/www/voorbeeld -type f -exec chmod 644 {} +
find /var/www/voorbeeld -type d -exec chmod 755 {} +
chmod 640 /var/www/voorbeeld/.envbash: ./script.sh: Permission denied betekent meestal dat de x-bit ontbreekt. Zet die alleen op het script zelf. Werkt het daarna nog niet, controleer dan of de schijf of map is gekoppeld met noexec, wat vaak voor /tmp geldt. Dan kun je het script nog wel starten via de interpreter.
chmod +x script.sh
findmnt -T /tmp -o TARGET,OPTIONS
bash script.shKan zelfs root een bestand niet wijzigen of verwijderen, dan kan het attribuut i (immutable) zijn gezet. lsattr laat dat zien, chattr -i haalt het weg. Ga na waarom het er stond: soms is het bewust gezet als bescherming.
lsattr /pad/naar/bestand
sudo chattr -i /pad/naar/bestandKloppen eigenaar en rechten wel, dan kan een beveiligingslaag de toegang tegenhouden. Op Red Hat-achtige systemen is dat vaak SELinux, op Ubuntu AppArmor. Bij SELinux moeten bestanden het juiste label hebben; restorecon zet de standaardlabels terug. Zet zo’n laag niet uit als oplossing, maar pas het label of profiel aan.
getenforce
ls -Z /var/www/html
sudo ausearch -m avc -ts recent
sudo restorecon -Rv /var/www/html
# AppArmor
sudo aa-status
sudo journalctl -k | grep -i apparmorUpload en deploy als de beheergebruiker en niet als root, dan krijgen nieuwe bestanden meteen de juiste eigenaar. Laat een deployscript na afloop eigenaar en rechten zetten. Zo hoef je niet steeds achteraf te repareren.
Let op: Zet nooit chmod 777 of chmod -R 777 als oplossing. Dan mag iedere gebruiker en elk proces op de server je bestanden wijzigen, inclusief een aanvaller die via een lek binnenkomt.
Beide komen in het Nederlands vaak neer op ‘geen toestemming’, maar de oorzaak verschilt:
Kom je er met deze stappen niet uit, of wil je het liever niet zelf doen? We kijken online mee of komen langs. Hulp op afstand kost €20 per uur; komen we langs, dan is de prijs op aanvraag. Je weet vooraf waar je aan toe bent.
Schrijf kort wat er misgaat en wat je al hebt geprobeerd. Kies of we bellen, online meekijken of langskomen.
De gebruiker waaronder het programma draait mag het bestand of de map niet lezen, schrijven of uitvoeren. Controleer de eigenaar en rechten met ls -l en namei -l.
Meestal 644 voor bestanden en 755 voor mappen, met schrijfrechten voor de webserver alleen op mappen als uploads en cache.
Iedereen op de server krijgt dan schrijfrechten. Een lek in één site of proces is genoeg om je bestanden te wijzigen.
Met chown verander je de eigenaar en groep van een bestand, met chmod de rechten die eigenaar, groep en overigen hebben.
Hulp nodig van een mens? Website-onderhoud · Hosting en onderhoud · WordPress-support · Alle oplossingen