nano bestand opslaan mislukt: permission denied oplossen

Waarom nano uw bestand niet opslaat

nano slaat uw bestand niet op vanwege een van de volgende vier redenen: u bent niet de eigenaar van het bestand, de bovenliggende map staat de actie van nano niet toe, het bestandssysteem is alleen-lezen of vol, of u bevindt zich in een container die onder een andere gebruikers-ID draait. De eerste twee zijn rechtenproblemen, de laatste twee niet. Controleer ze in die volgorde, omdat de eerste reden de meeste gevallen dekt, het slechts één commando kost om dit te bevestigen en de oplossing hiervoor sudoedit is in plaats van sudo nano.

Er gaat niets verloren zolang de editor nog geopend is. Uw tekst staat in het geheugen, dus u kunt het bestand open laten staan, de buffer naar een pad schrijven waarvan u wel de eigenaar bent, en het bestand daarna op de juiste plek plaatsen. Deze uitweg vindt u tegen het einde van deze handleiding.

Voer deze controles uit voordat u rechten wijzigt

Wijs elk commando naar het werkelijke pad dat u bewerkt. Ze beantwoorden verschillende vragen, dus voer ze allemaal uit voordat u actie onderneemt. Het wijzigen van rechten voordat u weet welke controle faalt, creëert meestal een tweede probleem bovenop het eerste.

id
ls -l /etc/nginx/nginx.conf
ls -ld /etc/nginx
namei -l /etc/nginx/nginx.conf
findmnt -no SOURCE,FSTYPE,OPTIONS -T /etc/nginx/nginx.conf
df -h /etc/nginx
df -i /etc/nginx

id toont de user ID en de group ID's die u op dit moment heeft. ls -l toont de eigenaar, de groep en de rechtenbits van het bestand zelf. ls -ld toont hetzelfde voor de map waarin het bestand staat; dit is een aparte vraag met een apart antwoord. namei -l doorloopt elk onderdeel van het pad en vermeldt de eigenaar en rechten van elk deel, waardoor beide vragen in één uitvoer worden beantwoord. findmnt benoemt het bestandssysteem onder dat pad en de opties waarmee het is aangekoppeld. df -h rapporteert de vrije ruimte en df -i rapporteert de vrije inodes, die onafhankelijk van de schijfruimte op kunnen raken. Als deze rechtenreeksen nog niet bekend zijn, begin dan bij hoe u de rechtenreeks leest die ls -l weergeeft.

Oorzaak 1: het bestand is eigendom van root en u bent dat niet

Lezen en schrijven zijn afzonderlijke rechten, en de meeste bestanden onder /etc zijn voor iedereen leesbaar. Daarom opent nano het bestand, toont het de inhoud en kunt u vrij typen: niets daarvan raakt de schijf aan. De weigering vindt plaats op het moment van opslaan, wanneer de kernel uw gebruikers-ID en groeps-ID's vergelijkt met de eigenaar, groep en overige bits van het bestand. nano geeft slechts door wat de kernel meldt, dus geen enkele nano-optie verandert de uitkomst.

id en ls -l lossen dit samen op. Het bestand is eigendom van root, u bent niet root, en de overige bits verlenen geen schrijfrechten. Nogmaals op Ctrl-O drukken helpt niet.

Waarom sudoedit de juiste manier is om een bestand van root te bewerken

SUDO_EDITOR=nano sudoedit /etc/nginx/nginx.conf

sudo maakt een tijdelijke kopie van het bestand aan waarvan u de eigenaar bent, voert nano uit op die kopie als uw eigen gebruiker, en kopieert het resultaat vervolgens terug naar de oorspronkelijke locatie met root-rechten zodra de editor wordt afgesloten. De editor draait nooit als root. sudo -e is hetzelfde commando onder een andere naam. De editor wordt gekozen uit SUDO_EDITOR, daarna VISUAL, en vervolgens EDITOR; het instellen van export EDITOR=nano in uw shell-profiel maakt dit dus overal de standaard. Als in uw sudoers de vlag env_editor is uitgeschakeld, worden deze variabelen genegeerd en wordt de editor bepaald door de instelling editor in sudoers.

sudo nano slaat het bestand ook op, en dat is het probleem. Het geeft een volledige interactieve editor root-rechten over het gehele bestandssysteem zolang de sessie actief is. Eén typefout in het pad bij de opslagprompt zorgt er dus voor dat uw tekst als root over een ander systeembestand wordt geschreven. Werken als een gewone gebruiker die sudo alleen aanroept voor de stappen die dat vereisen is een gewoonte die het waard is om aan te leren, en sudoedit is hoe die gewoonte eruitziet op het moment dat u een configuratiebestand bewerkt.

Twee regels van sudoedit verrassen mensen vaak. Het weigert een symbolische link te bewerken, en het weigert een bestand te bewerken in een map waar u naar kunt schrijven, tenzij u root bent. De tweede regel bestaat omdat iedereen die naar de map kan schrijven het bestand kan verwisselen terwijl de editor geopend is. Beide gedragingen zijn de standaardinstellingen van sudoers (sudoedit_follow uit, sudoedit_checkdir aan). Een bestand dat nog niet bestaat, wordt voor u aangemaakt.

Oorzaak 2: wat de bovenliggende map daadwerkelijk beheert

Advies voor andere editors stelt dat voor het opslaan schrijfrechten op de map vereist zijn, omdat veel editors opslaan door een nieuw bestand te schrijven en dit over het oude bestand heen te hernoemen. nano werkt niet op die manier. Het opent het opgegeven bestand en schrijft direct in dat bestand; voor een reeds bestaand bestand wordt de schrijfrechten-bit van de map dus nooit geraadpleegd.

De map bepaalt echter nog steeds andere zaken, wat de reden is dat ls -ld op de checklist staat:

• Voor het aanmaken van een bestand dat nog niet bestaat, zijn schrijf- en uitvoerrechten op de map vereist, omdat er een nieuwe naam aan moet worden toegevoegd. Uw umask bepaalt de rechten waarmee dat nieuwe bestand wordt aangemaakt.
• Om het bestand überhaupt te bereiken, zijn uitvoerrechten (ook wel zoekrechten genoemd) vereist op elke map in het pad. Als één map deze rechten mist, wordt alles daaronder geblokkeerd en laat namei -l u zien welke map dit is.
• Opslaan met back-ups of met ingeschakelde bestandsvergrendeling schrijft een tweede bestand naast het origineel; deze functies vereisen dus wel een beschrijfbare map. Back-ups zijn de -B optie of set backup in een nanorc, en vergrendeling is -G of set locking. Beide staan uit, tenzij u of uw distributie ze heeft ingeschakeld.

Maprechten wegen elders op het systeem even zwaar. De SSH-server weigert een sleutel wanneer uw home-map of uw .ssh-map door andere gebruikers kan worden gewijzigd; dit is een veelvoorkomende oorzaak van SSH dat uw sleutel afwijst bij het inloggen.

Omdat nano in het reeds aanwezige bestand schrijft, behoudt het bestand zijn inode, de identiteit op de schijf achter de naam. Alles wat het bestand open heeft staan, blijft het volgen, en een enkel bestand dat via een bind mount in een container is geplaatst, blijft werken. Editors die opslaan door het bestand te vervangen, verbreken die mount, omdat de mount de inode volgt en niet de naam.

Oorzaak 3: het bestandssysteem is alleen-lezen of de opslagruimte is uitgeput

findmnt rapporteren ro in de opties betekent dat de schrijfactie nooit zou slagen. Het bestandssysteem is op die manier aangekoppeld via /etc/fstab of een read-only bind mount, of de kernel heeft het na een schijffout opnieuw aangekoppeld als alleen-lezen. Het tweede geval is ernstig. sudo dmesg -T | tail -50 toont de input/output- en bestandssysteemfouten die tot de remount hebben geleid. De oplossing is een bestandssysteemcontrole terwijl het niet is aangekoppeld; op een VPS betekent dit opstarten via de rescue-console van de provider.

Een vol bestandssysteem faalt om een andere reden bij dezelfde schrijfactie. df -h dekt het normale geval. df -i dekt het geval dat vaak over het hoofd wordt gezien: inodes komen uit een vaste voorraad die wordt aangemaakt bij het formatteren van het bestandssysteem. Een boomstructuur met zeer kleine bestanden kan alle inodes verbruiken terwijl df -h nog steeds vrije gigabytes aangeeft. Wanneer de ruimte op is en niets voor de hand liggends de ruimte in beslag neemt, behandelt df en du geven verschillende waarden bij een volle schijf het scenario waarin een verwijderd maar nog geopend bestand de oorzaak is.

Eén detail verklaart hier een verwarrend symptoom. ext4 reserveert bij het aanmaken van het bestandssysteem een deel van de blokken voor root, waardoor root kan blijven schrijven nadat gewone gebruikers worden geweigerd. sudo lijkt dan de oplossing, maar de schijf vult zich vervolgens volledig en het probleem keert in ergere vorm terug.

Omdat nano het bestand inkort voordat de nieuwe inhoud wordt geschreven, kan een schrijfactie die halverwege zonder ruimte komt te zitten, het bestand korter achterlaten dan het was. Kopieer een configuratiebestand dat belangrijk is voordat u het bewerkt op een bestandssysteem dat bijna vol is. sudo cp -a /etc/nginx/nginx.conf /root/nginx.conf.bak behoudt de eigenaar, groep en rechten van de kopie.

Oorzaak 4: u bewerkt een bind mount binnen een container

Bestandseigendom is numeriek. De kernel slaat een user ID op en de naam die u ziet is afkomstig van de /etc/passwd die de opzoeking uitvoert. Hierdoor kan één bestand op de host een andere naam tonen dan in de container, of enkel een nummer weergeven. Vergelijk de nummers in plaats van de namen: voer id -u uit in de container en ls -ln op het bestand.

Een bind mounted bestand behoudt het eigendom dat het op de host heeft. Wanneer het hostbestand toebehoort aan uw gebruiker en het containerproces draait als een andere gebruiker, wordt schrijven in de container geweigerd. Bovendien wijzigt sudo binnen de container de eigenaar op de host niet. Los dit op vanaf de host door de eigenaar in te stellen op het ID waaronder de container draait, of start de container met het ID dat reeds eigenaar is van de bestanden. Images van linuxserver.io en vergelijkbare projecten stellen de PUID en PGID variabelen bloot waarmee u instelt als welke gebruiker het proces draait.

Er zijn nog twee gevallen met containers die relevant zijn. Een mount die met :ro op alleen-lezen is gezet, of een container die met --read-only is gestart, weigert schrijfacties ongeacht het eigendom. cat /proc/mounts toont in de container de bijbehorende vlag. Bij rootless Podman mapt een user namespace de user ID's van de container naar een reeks host-ID's. Hierdoor behoort een bestand dat in de container van root lijkt te zijn, buiten de container toe aan uw account zonder privileges.

Er is ook de bewerking die slaagt en vervolgens verdwijnt. Een bestand dat u binnen een container wijzigt op een pad dat geen mount is, bevindt zich in de beschrijfbare laag van die container. Deze laag wordt verwijderd wanneer de container opnieuw wordt aangemaakt. Wijzig het bestand aan de host-zijde van de mount, of in de image-build, als de wijziging permanent moet zijn.

De ontsnappingsroute: opslaan naar een pad waar u eigenaar van bent

Probeer geen privileges te verkrijgen vanuit de editor. Druk op Ctrl-O, wis het pad bij de prompt, typ een pad in uw home-directory zoals /home/you/nginx.conf.new en druk op Enter. Gebruik daarna Ctrl-X om af te sluiten. Uw werk staat nu op schijf, u bent de eigenaar en de rest is een standaard bestandskopie.

sudo cp /home/you/nginx.conf.new /etc/nginx/nginx.conf
sudo nginx -t

Gebruik hier cp in plaats van mv. cp schrijft door het bestaande bestand heen, waardoor de eigenaar, groep en permissies van dat bestand behouden blijven. mv op hetzelfde bestandssysteem vervangt het door uw bestand, waardoor een configuratie in /etc achterblijft die eigendom is van uw gebruikersaccount; dit wordt vervolgens het volgende permissieprobleem dat u moet oplossen.

Controleer het resultaat met de tool die het bestand beheert voordat u iets herlaadt. sudo nginx -t valideert de nginx-configuratie en sudo sshd -t valideert de SSH-serverconfiguratie. Twee bestanden hebben speciale editors die deze gehele procedure voor u uitvoeren: sudo visudo voor /etc/sudoers en crontab -e voor uw eigen cron-taken. Elke editor bewerkt een tijdelijke kopie, controleert de syntaxis en installeert het bestand alleen als de validatie slaagt.

FAQ

Moet ik sudo nano of sudoedit gebruiken om een systeembestand te bewerken?

Gebruik sudoedit. Dit kopieert het bestand naar een tijdelijke kopie waarvan u de eigenaar bent, voert uw editor uit als uw eigen gebruiker en schrijft het resultaat terug als root zodra de editor wordt afgesloten. Hierdoor krijgt de editor zelf nooit root-rechten. Stel SUDO_EDITOR, VISUAL of EDITOR in op nano om nano te selecteren. sudo nano werkt ook, maar geeft een interactieve editor root-toegang tot elk pad op het systeem gedurende de sessie. Eén typefout in een bestandsnaam bij het opslaan kan zo leiden tot een beschadigd systeembestand.

Heb ik schrijfrechten op de map nodig om een bestand op te slaan met nano?

Niet voor een bestand dat al bestaat. nano schrijft direct in het bestand zelf, dus de kernel controleert de schrijfbit op het bestand en de uitvoerbit op elke map in het pad. De schrijfbit van de map is alleen van belang als het bestand nog niet bestaat, omdat er dan een nieuwe naam moet worden aangemaakt, of wanneer back-ups of bestandsvergrendeling zijn ingeschakeld, omdat beide een tweede bestand naast het origineel schrijven.

De eigenaar lijkt correct en de schijf is niet vol. Wat kan het schrijven nog meer blokkeren?

Vier zaken. Het bestandssysteem kan zijn aangekoppeld als alleen-lezen, wat findmnt -no OPTIONS -T /etc/nginx/nginx.conf laat zien. Het bestand kan het onveranderlijke (immutable) attribuut hebben, wat lsattr toont en sudo chattr -i verwijdert; zelfs root kan het bestand niet wijzigen zolang dit is ingesteld. De inode-pool kan uitgeput zijn terwijl er nog vrije schijfruimte is, wat df -i aantoont. SELinux of AppArmor kan het schrijven weigeren, zelfs als de rechtenbits dit toestaan; het audit-logboek legt de weigering vast voor het pad dat u probeerde te bewerken.

Waar sla ik mijn wijzigingen op als het bestand helemaal niet wil opslaan?

Druk op Ctrl-O en geef een pad op waarvan u de eigenaar bent, in uw thuismap of op een andere locatie waar uw gebruiker schrijfrechten heeft. De buffer staat nog in het geheugen, dus er gaat niets verloren van wat u heeft getypt. Kopieer het opgeslagen bestand daarna naar de juiste locatie met sudo cp, wat de eigenaar en rechten van het originele bestand behoudt, en controleer het vervolgens met het eigen testcommando van de service voordat u de service herlaadt.

Waarom verdwijnen mijn wijzigingen in een Docker-container?

Wanneer het pad geen mount is, belandt de wijziging in de beschrijfbare laag van die container, en die laag wordt verwijderd wanneer de container wordt vervangen. Bewerk het bestand aan de host-zijde van een bind mount of een volume, of bouw het in de image. Wanneer het pad een bind mount is en het opslaan wordt geweigerd, vergelijk dan id -u in de container met de numerieke eigenaar uit ls -ln: het bestand behoudt zijn eigenaarschap van de host en het containerproces moet daarmee overeenkomen.