nano में 'Permission denied' एरर को कैसे ठीक करें

nano आपकी फाइल को सेव क्यों नहीं करेगा

nano आपकी फाइल को चार कारणों में से किसी एक के कारण सेव नहीं करेगा: आपके पास फाइल का स्वामित्व (ownership) नहीं है, पैरेंट डायरेक्टरी nano द्वारा किए जा रहे कार्य की अनुमति नहीं देती है, फाइलसिस्टम read-only है या उसमें जगह खत्म हो गई है, या आप किसी ऐसे कंटेनर के अंदर हैं जो अलग user ID के साथ चल रहा है। पहले दो कारण अनुमति (permission) संबंधी समस्याएं हैं, और अंतिम दो नहीं हैं। इनकी जांच इसी क्रम में करें, क्योंकि पहला कारण अधिकांश मामलों में लागू होता है, इसकी पुष्टि के लिए केवल एक कमांड की आवश्यकता होती है, और इसका समाधान sudo nano के बजाय sudoedit है।

जब तक एडिटर खुला है, तब तक कुछ भी नष्ट नहीं होता है। आपका टेक्स्ट मेमोरी में रहता है, इसलिए आप फाइल को खुला छोड़ सकते हैं, बफर को किसी ऐसे पाथ पर लिख सकते हैं जिसका स्वामित्व आपके पास है, और बाद में उसे सही स्थान पर रख सकते हैं। वह एस्केप हैच इस गाइड के अंत के पास है।

अनुमतियों (permissions) में कोई भी बदलाव करने से पहले इन जाँचों को चलाएं

प्रत्येक कमांड को उस वास्तविक पाथ (path) पर चलाएं जिसे आप संपादित कर रहे हैं। ये कमांड अलग-अलग सवालों के जवाब देते हैं, इसलिए किसी भी बदलाव से पहले इन सभी को चलाएं। यह जाने बिना कि कौन सी जाँच विफल हो रही है, अनुमतियों को बदलने से अक्सर पहली समस्या के ऊपर एक दूसरी समस्या पैदा हो जाती है।

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 वर्तमान में आपके पास मौजूद यूजर आईडी और ग्रुप आईडी को प्रिंट करता है। ls -l फाइल के मालिक, ग्रुप और उसके परमिशन बिट्स को दिखाता है। ls -ld उस डायरेक्टरी के लिए यही जानकारी दिखाता है जिसमें फाइल स्थित है, जो एक अलग सवाल है और जिसका जवाब भी अलग होता है। namei -l पाथ के हर हिस्से की जाँच करता है और प्रत्येक भाग के मालिक और अनुमतियों को सूचीबद्ध करता है, इसलिए यह एक ही आउटपुट में दोनों सवालों के जवाब देता है। findmnt उस पाथ के अंतर्गत फाइलसिस्टम का नाम और उन विकल्पों को बताता है जिनके साथ उसे माउंट किया गया है। df -h खाली जगह (free space) की रिपोर्ट देता है, और df -i खाली इनोड्स (free inodes) की रिपोर्ट देता है, जो डिस्क स्पेस से अलग समाप्त हो सकते हैं। यदि वे परमिशन स्ट्रिंग्स अभी तक परिचित नहीं हैं, तो ls -l द्वारा प्रिंट की गई परमिशन स्ट्रिंग को कैसे पढ़ें से शुरुआत करें।

कारण 1: फाइल root की है और आप मालिक नहीं हैं

पढ़ने और लिखने की अनुमतियाँ अलग-अलग होती हैं, और /etc के अंतर्गत अधिकांश फाइलें सभी के लिए पढ़ने योग्य होती हैं। यही कारण है कि nano फाइल को खोलता है, आपको सामग्री दिखाता है, और आपको स्वतंत्र रूप से टाइप करने देता है: इनमें से कोई भी क्रिया डिस्क को प्रभावित नहीं करती है। इनकार तब होता है जब आप फाइल को सेव करते हैं, क्योंकि उस समय kernel आपके user ID और group ID की तुलना फाइल के owner, group और अन्य bits से करता है। nano केवल वही जानकारी दे रहा है जो kernel ने उसे दी है, इसलिए nano का कोई भी विकल्प परिणाम नहीं बदल सकता है।

id और ls -l मिलकर इस समस्या का समाधान करते हैं। फाइल का मालिक root है, आप root नहीं हैं, और अन्य bits लिखने की अनुमति नहीं देते हैं। Ctrl-O को दोबारा दबाने से कोई मदद नहीं मिलेगी।

root-owned फाइल को एडिट करने के लिए sudoedit सही तरीका क्यों है

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

sudo फाइल की एक अस्थायी कॉपी बनाता है जिसका ओनर आपको सेट कर देता है, फिर उस कॉपी पर आपके यूजर के रूप में nano चलाता है, और एडिटर बंद होने पर रूट प्रिविलेज के साथ परिणाम को वापस मूल स्थान पर कॉपी कर देता है। एडिटर कभी भी रूट के रूप में नहीं चलता है। sudo -e एक अलग नाम के तहत वही कमांड है। एडिटर को SUDO_EDITOR, फिर VISUAL, और उसके बाद EDITOR से चुना जाता है, इसलिए आपके शेल प्रोफाइल में export EDITOR=nano इसे हर जगह डिफ़ॉल्ट बना देता है। यदि आपके sudoers में env_editor फ्लैग बंद है, तो उन वेरिएबल्स को अनदेखा कर दिया जाता है और एडिटर sudoers में editor सेटिंग से आता है।

sudo nano भी फाइल को सेव करता है, और यही समस्या है। यह सत्र के दौरान पूरे फाइलसिस्टम पर एक पूर्ण इंटरैक्टिव एडिटर को रूट प्रिविलेज देता है, इसलिए सेव प्रॉम्प्ट पर एक गलत टाइप किया गया पाथ आपके टेक्स्ट को रूट के रूप में किसी अन्य सिस्टम फाइल पर लिख सकता है। एक सामान्य यूजर के रूप में काम करना जो केवल उन चरणों के लिए sudo को कॉल करता है जिन्हें इसकी आवश्यकता है एक ऐसी आदत है जिसे विकसित करना सार्थक है, और जब आप किसी कॉन्फ़िगरेशन फाइल को एडिट करते हैं तो sudoedit उसी आदत का हिस्सा है।

दो sudoedit नियम लोगों को आश्चर्यचकित करते हैं। यह सिम्बॉलिक लिंक को एडिट करने से मना कर देता है, और यह ऐसी डायरेक्टरी के अंदर की फाइल को एडिट करने से मना कर देता है जिसमें आप लिख सकते हैं, जब तक कि आप रूट न हों। दूसरा नियम इसलिए मौजूद है क्योंकि जो कोई भी डायरेक्टरी में लिख सकता है, वह एडिटर के खुले रहने के दौरान फाइल को बदल सकता है। दोनों व्यवहार sudoers के डिफ़ॉल्ट हैं (sudoedit_follow बंद, sudoedit_checkdir चालू)। जो फाइल अभी तक मौजूद नहीं है, वह आपके लिए बना दी जाती है।

कारण 2: पैरेंट डायरेक्टरी वास्तव में क्या नियंत्रित करती है

अन्य एडिटर्स के लिए लिखी गई सलाह कहती है कि सेव करने के लिए डायरेक्टरी पर राइट परमिशन की आवश्यकता होती है, क्योंकि कई एडिटर्स एक नई फाइल लिखकर उसे पुरानी फाइल के ऊपर रीनेम करके सेव करते हैं। nano इस तरह काम नहीं करता है। यह आपके द्वारा नामित फाइल को खोलता है और सीधे उसी फाइल में लिखता है, इसलिए यदि फाइल पहले से मौजूद है, तो डायरेक्टरी के राइट बिट (write bit) की जांच कभी नहीं की जाती है।

डायरेक्टरी अभी भी अन्य चीजों को निर्धारित करती है, यही कारण है कि चेक लिस्ट में ls -ld शामिल है:

• ऐसी फाइल बनाना जो अभी मौजूद नहीं है, उसके लिए डायरेक्टरी पर राइट और एक्जीक्यूट परमिशन की आवश्यकता होती है, क्योंकि इसमें एक नया नाम जोड़ना पड़ता है। आपकी umask यह तय करती है कि नई फाइल किन परमिशन के साथ शुरू होगी।
• फाइल तक पहुँचने के लिए पाथ में आने वाली हर डायरेक्टरी पर एक्जीक्यूट परमिशन, जिसे सर्च परमिशन भी कहा जाता है, आवश्यक है। यदि किसी एक डायरेक्टरी में यह परमिशन नहीं है, तो उसके नीचे की हर चीज ब्लॉक हो जाती है, और namei -l आपको दिखाता है कि वह कौन सी डायरेक्टरी है।
• बैकअप के साथ या फाइल लॉकिंग चालू होने पर सेव करने से ओरिजिनल फाइल के बगल में एक दूसरी फाइल लिखी जाती है, इसलिए उन फीचर्स के लिए राइट करने योग्य डायरेक्टरी की आवश्यकता होती है। बैकअप -B विकल्प या nanorc में set backup है, और लॉकिंग -G या set locking है। जब तक आप या आपका डिस्ट्रिब्यूशन इन्हें चालू न करे, ये दोनों बंद रहते हैं।

डायरेक्टरी परमिशन का सिस्टम में अन्य जगहों पर भी उतना ही महत्व है। SSH सर्वर तब की (key) को अस्वीकार कर देता है जब आपकी होम डायरेक्टरी या आपकी .ssh डायरेक्टरी को अन्य यूजर्स द्वारा लिखा जा सकता है, जो लॉगिन के समय SSH द्वारा आपकी की को अस्वीकार करने का एक सामान्य कारण है।

चूंकि nano पहले से मौजूद फाइल में ही लिखता है, इसलिए फाइल अपना inode बनाए रखती है, जो नाम के पीछे की ऑन-डिस्क पहचान है। जो भी प्रोसेस फाइल को ओपन रखती है, वह उसे ट्रैक करती रहती है, और कंटेनर में bind mount की गई एक सिंगल फाइल काम करती रहती है। जो एडिटर्स फाइल को रिप्लेस करके सेव करते हैं, वे उस माउंट को तोड़ देते हैं, क्योंकि माउंट inode का अनुसरण करता है, नाम का नहीं।

कारण 3: फाइलसिस्टम read-only है, या उसमें जगह खत्म हो गई है

findmnt विकल्पों में ro रिपोर्ट करने का अर्थ है कि write ऑपरेशन कभी सफल नहीं हो सकता था। या तो फाइलसिस्टम को /etc/fstab के माध्यम से या read-only bind mount के रूप में उसी तरह माउंट किया गया था, या डिस्क त्रुटि के बाद कर्नल ने इसे read-only मोड में रीमाउंट कर दिया। दूसरा मामला गंभीर है। sudo dmesg -T | tail -50 उन इनपुट/आउटपुट और फाइलसिस्टम त्रुटियों को दिखाता है जिनके कारण रीमाउंट हुआ, और इसका समाधान अनमाउंट होने पर फाइलसिस्टम चेक करना है, जो VPS के मामले में प्रदाता के rescue console से बूट करने का अर्थ रखता है।

एक भरा हुआ फाइलसिस्टम अलग कारण से उसी write ऑपरेशन को विफल कर देता है। df -h सामान्य स्थिति को कवर करता है। df -i उस स्थिति को कवर करता है जिसे लोग नजरअंदाज कर देते हैं: inodes एक निश्चित पूल से आते हैं जो फाइलसिस्टम बनाते समय तैयार किया जाता है, और छोटी फाइलों का एक ट्री उन सभी का उपयोग कर सकता है जबकि df -h अभी भी खाली गीगाबाइट दिखाता है। जब जगह खत्म हो जाती है और कुछ भी स्पष्ट रूप से इसे नहीं रोक रहा होता है, तो df और du का फुल डिस्क के बारे में असहमत होना उस डिलीट की गई लेकिन अभी भी खुली फाइल को कवर करता है जो इसका कारण बनती है।

यहाँ एक विवरण एक भ्रमित करने वाले लक्षण की व्याख्या करता है। ext4 फाइलसिस्टम बनाते समय root के लिए अपने ब्लॉक्स का एक हिस्सा आरक्षित करता है, इसलिए सामान्य उपयोगकर्ताओं को मना किए जाने के बाद भी root लिखना जारी रखता है। sudo तब समाधान जैसा दिखता है, डिस्क बाकी बची जगह तक भर जाती है, और समस्या और भी बदतर रूप में वापस आ जाती है।

चूंकि nano नई सामग्री लिखने से पहले फाइल को ट्रंकेट (truncate) कर देता है, इसलिए जो write ऑपरेशन बीच में ही जगह खत्म होने के कारण रुक जाता है, वह फाइल को पहले से छोटा छोड़ सकता है। जिस कॉन्फ़िगरेशन की आपको परवाह है, उसे लगभग भरे हुए फाइलसिस्टम पर संपादित करने से पहले उसकी कॉपी बना लें। sudo cp -a /etc/nginx/nginx.conf /root/nginx.conf.bak कॉपी पर ओनर, ग्रुप और अनुमतियों (permissions) को सुरक्षित रखता है।

कारण 4: आप एक container के अंदर bind mount को edit कर रहे हैं

File ownership संख्यात्मक (numeric) होती है। Kernel एक user ID को store करता है, और जो नाम आप देखते हैं वह उस /etc/passwd से आता है जो lookup करता है। इसलिए, एक ही file host पर एक नाम और container के अंदर दूसरा नाम, या केवल एक संख्या दिखा सकती है। नामों के बजाय संख्याओं की तुलना करें: container के अंदर id -u चलाएं और file पर ls -ln चलाएं।

Bind mount की गई file वही ownership रखती है जो host पर होती है। जब host file आपके user की होती है और container process किसी अलग user के रूप में चलती है, तो container के अंदर write करने से मना कर दिया जाता है, और container के अंदर sudo चलाने से host पर owner नहीं बदलता है। इसे host से उस ID पर owner सेट करके ठीक करें जिस पर container चलता है, या container को उस ID के रूप में चलाएं जो पहले से ही files का मालिक है। linuxserver.io और इसी तरह के projects के images PUID और PGID variables को expose करते हैं जो यह तय करते हैं कि process किस user के रूप में चलेगी।

दो और container स्थितियों के बारे में जानना उपयोगी है। :ro के साथ read-only बनाया गया mount, या --read-only के साथ शुरू किया गया container, ownership चाहे जो भी हो, write करने से मना कर देता है, और container के अंदर cat /proc/mounts वह flag दिखाता है। Rootless Podman के साथ, एक user namespace container के user IDs को host IDs की एक range पर map करता है, इसलिए जो file container के अंदर root की लगती है, वह बाहर आपके unprivileged account की होती है।

एक ऐसी edit भी होती है जो सफल हो जाती है और फिर गायब हो जाती है। एक file जिसे आप container के अंदर बदलते हैं, ऐसे path पर जो mount नहीं है, वह उस container की writable layer में रहती है, और container को recreate करने पर वह layer हटा दी जाती है। यदि बदलाव को स्थायी रखना है, तो mount के host side पर, या image build में file को बदलें।

एस्केप हैच: इसे अपने स्वामित्व वाले पाथ पर सेव करें

एडिटर के भीतर से प्रिविलेज प्राप्त करने का प्रयास न करें। Ctrl-O दबाएं, प्रॉम्प्ट पर पाथ को क्लियर करें, अपनी होम डायरेक्टरी के अंतर्गत एक पाथ टाइप करें जैसे कि /home/you/nginx.conf.new, और Enter दबाएं। फिर बाहर निकलने के लिए Ctrl-X दबाएं। आपका काम अब डिस्क पर है, जिसका स्वामित्व आपके पास है, और बाकी एक सामान्य फाइल कॉपी है।

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

यहाँ mv के बजाय cp का उपयोग करें। cp पहले से मौजूद फाइल के माध्यम से लिखता है, इसलिए वह फाइल अपना ओनर, ग्रुप और परमिशन बनाए रखती है। एक ही फाइलसिस्टम पर mv इसे आपकी फाइल से बदल देता है, जिससे /etc में एक कॉन्फ़िगरेशन आपके यूजर अकाउंट के स्वामित्व में आ जाता है, और यह अगली परमिशन समस्या बन जाती है जिसे आपको हल करना होगा।

किसी भी चीज़ को रीलोड करने से पहले उस टूल के साथ परिणाम की जाँच करें जो फाइल का मालिक है। sudo nginx -t nginx कॉन्फ़िगरेशन को पार्स करता है, और sudo sshd -t SSH सर्वर कॉन्फ़िगरेशन को पार्स करता है। दो फाइलों में समर्पित एडिटर होते हैं जो आपके लिए यह पूरी प्रक्रिया करते हैं: /etc/sudoers के लिए sudo visudo और आपके अपने cron जॉब्स के लिए crontab -e। प्रत्येक एक अस्थायी कॉपी को एडिट करता है, सिंटैक्स की जाँच करता है, और फाइल को तभी इंस्टॉल करता है यदि वह पार्स हो जाती है।

FAQ

क्या मुझे सिस्टम फाइल एडिट करने के लिए sudo nano या sudoedit का उपयोग करना चाहिए?

sudoedit का उपयोग करें। यह फाइल की एक अस्थायी कॉपी आपके यूजर के नाम पर बनाता है, आपके एडिटर को आपके यूजर के रूप में चलाता है, और एडिटर बंद होने पर परिणाम को root के रूप में वापस लिख देता है। इस प्रकार एडिटर को कभी भी root विशेषाधिकार नहीं मिलते हैं। nano चुनने के लिए SUDO_EDITOR, VISUAL या EDITOR को nano पर सेट करें। sudo nano भी काम करता है, लेकिन यह सेशन के दौरान एक इंटरैक्टिव एडिटर को सिस्टम के हर पाथ पर root एक्सेस दे देता है। इससे सेव प्रॉम्प्ट पर एक गलत टाइप किया गया फाइलनाम सिस्टम फाइल को नुकसान पहुँचा सकता है।

क्या nano के साथ फाइल सेव करने के लिए डायरेक्टरी पर राइट परमिशन होना जरूरी है?

जो फाइल पहले से मौजूद है, उसके लिए नहीं। nano सीधे फाइल के अंदर लिखता है, इसलिए कर्नल फाइल पर राइट बिट और पाथ की हर डायरेक्टरी पर एग्जीक्यूट बिट की जांच करता है। डायरेक्टरी का राइट बिट तब मायने रखता है जब फाइल अभी तक मौजूद न हो, क्योंकि तब एक नया नाम बनाना पड़ता है। साथ ही, जब बैकअप या फाइल लॉकिंग चालू हो, तब भी इसकी आवश्यकता होती है क्योंकि ये दोनों मूल फाइल के बगल में एक दूसरी फाइल लिखते हैं।

ओनर सही दिख रहा है और डिस्क फुल नहीं है। और क्या चीज राइट करने से रोक सकती है?

चार चीजें। फाइलसिस्टम read-only मोड में माउंट हो सकता है, जिसे findmnt -no OPTIONS -T /etc/nginx/nginx.conf दिखाता है। फाइल पर immutable एट्रिब्यूट हो सकता है, जिसे lsattr दिखाता है और sudo chattr -i हटाता है; इसे सेट रहने पर root भी फाइल में नहीं लिख सकता। डिस्क पर खाली जगह होने के बावजूद inode पूल खत्म हो सकता है, जिसे df -i दिखाता है। SELinux या AppArmor परमिशन बिट्स की अनुमति के बावजूद राइट करने से मना कर सकते हैं, और ऑडिट लॉग उस पाथ पर हुई मनाही को रिकॉर्ड करता है।

जब फाइल बिल्कुल भी सेव न हो, तो मैं अपने बदलाव कहाँ रखूँ?

Ctrl-O दबाएं और एक ऐसा पाथ दें जिस पर आपका अधिकार हो, जैसे आपकी होम डायरेक्टरी या कोई अन्य स्थान जहाँ आपका यूजर लिख सके। बफर अभी भी मेमोरी में है, इसलिए आपने जो कुछ भी टाइप किया है वह खोएगा नहीं। बाद में सेव की गई फाइल को sudo cp के साथ सही जगह पर कॉपी करें, जो मूल फाइल के ओनर और परमिशन को बनाए रखता है। इसके बाद सर्विस को रीलोड करने से पहले सर्विस के अपने टेस्ट कमांड से इसकी जांच करें।

Docker कंटेनर के अंदर किए गए मेरे बदलाव क्यों गायब हो जाते हैं?

जब पाथ माउंट नहीं होता है, तो बदलाव कंटेनर की राइटेबल लेयर में चले जाते हैं, और कंटेनर को रिप्लेस करने पर वह लेयर हटा दी जाती है। फाइल को bind mount या volume के होस्ट साइड पर एडिट करें, या उसे इमेज में ही बिल्ड करें। जब पाथ एक bind mount हो और सेव करने से मना कर दिया जाए, तो कंटेनर के अंदर id -u की तुलना ls -ln से मिलने वाले न्यूमेरिक ओनर से करें: फाइल अपना होस्ट ओनरशिप बनाए रखती है, और कंटेनर प्रोसेस को उससे मेल खाना चाहिए।