Linux में Permission denied क्यों आता है और क्या करें

Permission denied का मतलब क्या है

Permission denied का हिंदी में सीधा अर्थ है: अनुमति नहीं है। यह message यह भी बताता है कि आपका command सही लिखा गया था और रास्ता भी मौजूद था, क्योंकि गलत command पर shell command not found कहता है और गलत रास्ते पर No such file or directory आता है। मना आख़िरी पल में हुआ, जब kernel ने आपकी पहचान की तुलना उस file या directory के अधिकारों से की और दोनों मेल नहीं खाए।

यह फ़ैसला दो बातों की तुलना से बनता है: आप कौन हैं, और target किसे क्या देता है। इसलिए हर जाँच इन्हीं दो सवालों के इर्द-गिर्द घूमती है। इस पन्ने का काम कारण ढूँढना है, इलाज बाद की बात है, क्योंकि गलत कारण पर लगाया गया सही इलाज भी अगले हफ़्ते वही समस्या लौटा देता है।

यहाँ के commands Ubuntu 24.04 के लिए लिखे गए हैं। हर command उसी user के रूप में चलाइए जिसे समस्या आ रही है, root के रूप में नहीं। root को file mode की रोक लगती ही नहीं, इसलिए sudo लगाकर जाँच करने पर लक्षण गायब हो जाता है और कारण छिपा रह जाता है।

अपना output पढ़िए, किसी default मान का अंदाज़ा मत लगाइए

नीचे हर कदम पर आपसे एक command चलाने और अपना output पढ़ने को कहा गया है। इसकी वजह साफ़ है: हर server पर user का नाम, समूह, mode और umask अलग होते हैं, और किसी छपे हुए मान को अपने server का मान मान लेना ही सबसे आम गलती है। मैं आपको यह नहीं बताऊँगा कि आपकी file का mode क्या होगा। मैं यह बताऊँगा कि आपके output की कौन सी line देखनी है और वह क्या साबित करती है।

संदेश को भी पूरा पढ़िए। हर Permission denied तीन हिस्सों में आता है: शुरू में वह program जो शिकायत कर रहा है (bash, ls, cp, mkdir), बीच में वह path जिस पर रोक लगी, और अंत में कारण। बीच वाला path ही असली जानकारी है, क्योंकि अक्सर वह वही नहीं होता जो आपने टाइप किया था।

जाँच का क्रम

1. id से देखिए कि shell आपको कौन समझता है।
2. ls -ld और stat से देखिए कि target किसका है और क्या देता है।
3. namei -l से पूरे रास्ते की हर parent directory देखिए।
4. तय कीजिए कि रोक स्वामित्व की है या mode की।
5. अगर script है तो निष्पादन बिट और फिर noexec देखिए।
6. तब जाकर सबसे छोटा सुधार लगाइए।

पहला कदम: shell आपको कौन समझता है

id

id का output एक ही line में आता है और उसमें तीन खाने काम के हैं।

• uid= के आगे आपका user id और कोष्ठक में उसका नाम रहता है। यही वह पहचान है जिससे kernel तुलना करेगा।
• gid= आपका प्राथमिक समूह (primary group) है। आपकी बनाई नई files आमतौर पर इसी समूह के नाम होती हैं।
• groups= में वे सारे समूह हैं जिनके आप सदस्य हैं। mode का समूह वाला खंड तभी लागू होगा जब file का समूह इस सूची में मौजूद हो।

अब एक ऐसी बात जो घंटों बचाती है। समूह की सदस्यता आपके login के समय तय होती है और चल रहे session में अपने आप नहीं बदलती। किसी user को अभी-अभी किसी समूह में जोड़ा गया है, तो उस user के पुराने shell का id उस समूह को नहीं दिखाएगा, और रोक बनी रहेगी। log out करके दोबारा login कीजिए, या newgrp <समूह> चलाकर उसी shell में नया समूह लीजिए, और फिर id दोबारा चलाकर पुष्टि कीजिए कि समूह अब सूची में है।

दूसरा कदम: target क्या देता है

ls -ld /path/to/target
stat /path/to/target

-ld में d ज़रूरी है। directory पर सादा ls -l उसके अंदर की चीज़ें दिखाता है, जबकि आपको ख़ुद उस directory की entry देखनी है। -d वही करता है।

ls -ld की पहली column वह mode string है जिससे सब कुछ शुरू होता है। उसका पहला अक्षर बताता है कि यह क्या है, जैसे directory (निर्देशिका) के लिए d और साधारण file के लिए -। उसके बाद तीन-तीन अक्षरों के तीन खंड आते हैं: पहला खंड owner यानी स्वामी का, दूसरा group यानी समूह का, तीसरा others यानी बाक़ी सबका। हर खंड में पढ़ने के लिए r, लिखने के लिए w और चलाने या आर-पार जाने के लिए x आता है, और जो अधिकार नहीं है उसकी जगह - दिखता है। इन अक्षरों को एक-एक करके पढ़ने की पूरी विधि drwxr-xr-x जैसी mode string को अक्षर दर अक्षर पढ़ने वाली गाइड में है।

यहाँ वह नियम है जिसे लोग उलटा समझ लेते हैं: तीनों खंडों में से सिर्फ़ एक लागू होता है। अगर आपका uid file के owner से मेल खाता है, तो सिर्फ़ owner वाले तीन बिट पढ़े जाते हैं और बाक़ी दोनों खंड देखे ही नहीं जाते। इसका नतीजा उल्टा लग सकता है: owner होते हुए भी अगर owner खंड में w नहीं है, तो आप उस file में नहीं लिख सकते, चाहे others खंड में w खुला पड़ा हो।

stat वही जानकारी खोलकर देता है। उसके output की जिस line में Access: लिखा है, उसमें कोष्ठक के अंदर पहले संख्या वाला mode और फिर वही mode अक्षरों में आता है, और उसी line में आगे Uid: और Gid: संख्या तथा नाम दोनों रूप में दिखते हैं। यही वह line है जिसे आपको अगले कदम में id के साथ मिलाना है। इससे नीचे Access:, Modify: और Change: वाली समय की lines अलग होती हैं, उन्हें इस जाँच में मत मिलाइए।

अगर ls -ld की mode string के आख़िर में एक + चिपका दिखे, तो उस path पर ACL लगी है और असली अनुमति सिर्फ़ mode से तय नहीं हो रही। ऐसी हालत में getfacl /path/to/target चलाइए और उसकी सूची में अपना user या अपना कोई समूह ढूँढिए।

तीसरा कदम: बंद parent directory खुली file को भी बेकार कर देती है

यह वह कारण है जो सबसे ज़्यादा लोगों को चकराता है। किसी file तक पहुँचने के लिए kernel को उसके पूरे रास्ते से गुज़रना पड़ता है, एक-एक directory करके। directory का x बिट पढ़ने का नहीं, आर-पार जाने का अधिकार है। बीच की किसी एक directory में आपके लागू खंड में x नहीं है, तो उससे आगे की file आपके लिए मौजूद ही नहीं है, चाहे वह file दुनिया भर के लिए पढ़ने योग्य क्यों न हो। इसलिए सिर्फ़ file देखकर निष्कर्ष निकालना अधूरी जाँच है।

namei -l /path/to/target

namei -l पूरे रास्ते की हर कड़ी को अलग line में, mode, owner और समूह समेत छापता है। इसे ऊपर से नीचे पढ़िए और पहली ऐसी line ढूँढिए जिसमें आप पर लागू होने वाले खंड में x गायब है। उससे नीचे की सारी lines बेमतलब हैं, क्योंकि आप वहाँ तक पहुँचते ही नहीं। यही आपकी असली रोक है और सुधार इसी line पर होगा, नीचे वाली file पर नहीं।

directory पर r और x दो अलग काम करते हैं, और इनका फ़र्क़ आपके लक्षण बदल देता है। r नाम पढ़ने देता है और x किसी नाम की entry खोलने देता है। जिस directory में r है पर x नहीं, वहाँ ls नाम तो दिखा देगा, पर ls -l हर नाम पर रुक जाएगा और खानों में ? भरकर शिकायत करेगा। उल्टी हालत में, जहाँ x है पर r नहीं, ls मना कर देगा, फिर भी अगर आपको अंदर की file का पूरा नाम पहले से पता है तो cat उसे खोल लेगा।

रोक स्वामित्व की है या mode की

अब id का uid= और stat का Uid: आमने-सामने रखिए, और id का groups= तथा stat का Gid: भी। इसके बाद फ़ैसला सीधा है।

• दोनों uid एक हैं, यानी file आपकी है और फिर भी रोक है। तब रोक mode की है, और सुधार mode पर लगेगा।
• uid अलग है पर file का समूह आपकी groups= सूची में है। तब आप पर समूह वाला खंड लागू है, और उसी खंड में ज़रूरी अक्षर गायब है।
• uid अलग है और समूह भी आपका नहीं। तब आप पर others खंड लागू है, और असल में यह स्वामित्व का मामला है।

स्वामित्व वाले मामले में दो ईमानदार रास्ते हैं। पहला, आप उस समूह के सदस्य बन जाएँ जिसे पहले से अधिकार है। यह सबसे कम दख़ल वाला रास्ता है और तब सही है जब file किसी चलती हुई सेवा की है, क्योंकि सेवा का अपना user वैसे का वैसा रहता है। दूसरा, file का owner बदल दिया जाए। यह तभी कीजिए जब file सचमुच आपकी होनी चाहिए, जैसे आपके home में पड़ी कोई चीज़ जो गलती से किसी और के नाम चढ़ गई, और उसका सही तरीक़ा chown से स्वामित्व वापस अपने user को देने वाली गाइड में है। किसी सेवा की directory का owner अपने नाम कर लेना उस सेवा को अगले restart पर तोड़ देता है।

एक और सवाल यहीं निपट जाता है: नई बनी file पर रोक क्यों। नई files का शुरुआती mode आपकी umask तय करती है, इसलिए अभी-अभी बनाई गई file भी किसी और user के लिए बंद निकल सकती है, और यह किसी गड़बड़ी का संकेत नहीं है। umask नई files को कौन सा mode देता है, यह एक बार समझ लेने पर ऐसे मामले पहचानना आसान हो जाता है। जिस file को आप editor में खोलकर सेव नहीं कर पा रहे, उसका अलग लक्षण nano में file सेव न होने वाली स्थिति में खुलता है, क्योंकि कई editor सेव करते समय नई file बनाते हैं और उसके लिए file का नहीं, उसकी directory का w चाहिए होता है।

script चलती क्यों नहीं

अगर ./deploy.sh पर रोक लगी है, तो कारण तय करने के लिए एक ही test काफ़ी है।

bash deploy.sh

अगर यह चल गया, तो पढ़ने की अनुमति मौजूद है और चलाने की नहीं। वजह यह है कि bash deploy.sh में kernel bash को चलाता है और bash उस file को सिर्फ़ पढ़ता है, जिसके लिए r काफ़ी है। जबकि ./deploy.sh में kernel को ख़ुद उस file को चलाना पड़ता है, और उसके लिए आप पर लागू खंड में निष्पादन बिट (execute bit) यानी x चाहिए। यही बिट गायब है।

chmod u+x deploy.sh

सबसे छोटा सुधार यही है: सिर्फ़ owner को चलाने का अधिकार। chmod +x तीनों खंडों को एक साथ यह अधिकार दे देता है, जो साझा server पर ज़रूरत से ज़्यादा है। अक्षरों वाले और संख्या वाले दोनों तरीक़ों का फ़र्क़ chmod के numeric और symbolic mode में खुलकर मिलेगा। ध्यान रहे कि script की पहली line में जो interpreter लिखा है, वह भी चलने योग्य होना चाहिए, वरना रोक script की नहीं, उस interpreter की होगी।

filesystem कहीं noexec तो नहीं है

मान लीजिए ls -l में x साफ़ दिख रहा है और ./deploy.sh फिर भी वही जवाब दे रहा है। अब सवाल file का नहीं, उस filesystem का है जिस पर file रखी है।

findmnt -T ./deploy.sh

findmnt -T उस path को सँभालने वाले mount की line छापता है, जिसमें mount point, device, filesystem का प्रकार और माउंट विकल्प (mount options) आते हैं। विकल्पों वाले खाने में noexec लिखा दिखे, तो उस filesystem से कोई भी program नहीं चलेगा, mode चाहे जो हो और user चाहे कोई भी हो। कई server पर /tmp और /dev/shm जानबूझकर इसी तरह माउंट किए जाते हैं, ताकि वहाँ गिरी हुई कोई भी चीज़ चल न सके।

यहाँ सही इलाज mount बदलना नहीं है। script को अपनी home directory जैसी किसी ऐसी जगह ले जाइए जो noexec नहीं है, और वहीं से चलाइए। /etc/fstab से noexec हटाना एक सुरक्षा उपाय को पूरे server के लिए बंद कर देता है, सिर्फ़ इसलिए कि एक script गलत जगह रखी थी।

sudo कब सही जवाब है

sudo तब सही है जब काम सचमुच administrator का है: /etc में कोई config बदलना, package install करना, किसी service को चलाना या रोकना, दूसरे users की चीज़ें देखना। ऐसी जगहों पर रोक लगना गड़बड़ी नहीं, डिज़ाइन है। sudo -l चलाकर देख लीजिए कि आपको किन commands की इजाज़त दी गई है।

दूसरी तरफ़, अगर अपनी ही home directory की किसी file पर sudo लगाना पड़ रहा है, तो sudo जवाब नहीं है, इशारा है कि कहीं कुछ और टूटा है। असली सवाल यह है कि आपकी file का owner root कैसे बना। सबसे आम वजह यह है कि वही काम पहले किसी बार sudo लगाकर किया गया था, और उस समय बनी सारी files root के नाम चढ़ गईं। stat से पुष्टि कीजिए, फिर उन्हीं files का owner वापस अपने user को दीजिए। पूरी directory पर chmod 777 की चादर डालने से लक्षण ज़रूर हट जाएगा, पर owner root ही रहेगा और अगली गड़बड़ी उसी जगह से निकलेगी।

एक जाल यहाँ बार-बार पकड़ता है। नीचे वाला command sudo के बावजूद मना करेगा।

sudo echo 'line' >> /etc/some.conf

कारण यह है कि >> को आपका shell सँभालता है, और वह उस file को आपके अपने अधिकार से खोलता है, sudo के चलने से भी पहले। यानी sudo तक बात पहुँचने से पहले ही रोक लग चुकी होती है। सही रूप ये हैं।

echo 'line' | sudo tee -a /etc/some.conf
sudo sh -c 'echo line >> /etc/some.conf'

सब ठीक दिखने पर भी रोक लगे तो

अगर id, stat और namei -l तीनों साफ़ दिख रहे हैं, तो रोक mode की परत से बाहर कहीं है। इन जगहों पर देखिए।

• ACL लगी हो सकती है। getfacl से पूरी सूची देखिए, क्योंकि mode string सिर्फ़ + चिपकाकर इसका संकेत देती है।
• Ubuntu पर AppArmor डिफ़ॉल्ट रूप से चलता है और किसी program को उसके अपने profile के बाहर जाने से रोक सकता है। sudo dmesg -T चलाकर उसमें DENIED शब्द खोजिए और देखिए कि किस program के लिए और किस path पर entry आई है।
• file पर immutable attribute लगा हो सकता है। lsattr file में i दिखे तो बदलाव root के लिए भी मना है, और message Operation not permitted वाला आता है। sudo chattr -i file उसे हटाता है।
• filesystem read-only हो सकता है, पर तब message अलग होता है और उसमें Read-only file system लिखा मिलता है। यह अक्सर disk में error मिलने के बाद होता है, इसलिए dmesg भी देखिए।
• disk भर जाने पर रोक जैसा लक्षण दिखता है, पर message No space left on device होता है। यह अपनी अलग जाँच माँगता है, और df और du के अलग-अलग जवाब देने वाला मामला वहीं से शुरू होता है।

संदर्भ भी मायने रखता है, क्योंकि एक ही command आपके shell में चलती है और किसी और जगह रुक जाती है। container के अंदर uid का mapping बाहर वाले uid से अलग होता है, इसलिए host पर ठीक दिखती file container के process के लिए पराई होती है, और यही गाँठ Docker में PUID और PGID तय करने वाली गाइड में खुलती है। cron से चलने वाली script का environment और उसका working directory आपके login shell जैसा नहीं होता, इसलिए वही script हाथ से चलने पर चलती है और समय पर नहीं, और यह cron job के न चलने के कारणों में सबसे ऊपर आता है। और अगर रोक login के समय ही लग रही है, तो वह file की नहीं, SSH की परत है: उसका अपना Permission denied (publickey) वाला अलग इलाज है, जिसमें key की अपनी अनुमतियाँ भी शामिल हैं।

सबसे छोटा सुधार चुनिए

जब कारण मिल जाए, तो सुधार उतना ही होना चाहिए जितना पहुँच लौटाने के लिए ज़रूरी है। किसी एक file का निष्पादन बिट लगाना, किसी एक parent directory में x देना, या अपने user को सही समूह में जोड़ना: ये तीनों सुधार छोटे हैं और बाद में पढ़े जा सकते हैं। chmod -R 777 इसके उलट काम करता है। वह चलता इसलिए है कि उसने सवाल ही मिटा दिया, जवाब नहीं दिया। उसके बाद उस जगह हर user लिख सकता है, और sticky bit न हो तो मिटा भी सकता है। web server की directory पर इसका मतलब है कि कोई भी वहाँ फाइल बदल सकता है।

सुधार लगाने के बाद वही पहला command दोबारा चलाइए जिस पर रोक लगी थी, और उसी user के रूप में चलाइए। अगर अब वह चल जाता है, तो आपका कारण सही था। अगर नहीं चलता, तो सुधार वापस हटा दीजिए और namei -l पर लौटिए, क्योंकि रास्ते में एक से ज़्यादा रुकावट हो सकती हैं और वे एक-एक करके ही खुलती हैं।

FAQ

chmod 777 से काम चल जाता है, तो वह गलत क्यों है?

chmod 777 इसलिए चलता है कि वह owner, समूह और बाक़ी सबको सारे अधिकार दे देता है, यानी रोक का सवाल ही ख़त्म कर देता है। इससे दो नुक़सान होते हैं। पहला, उस जगह पर server का कोई भी user लिख सकता है, और sticky bit न होने पर मिटा भी सकता है, जो किसी web या data directory पर सीधा जोखिम है। दूसरा, असली कारण दर्ज ही नहीं होता, इसलिए वही समस्या अगली file पर दोबारा आती है। पहले id और namei -l से कारण पक्का कीजिए, फिर उसी एक जगह पर सबसे छोटा बदलाव लगाइए।

sudo लगाने के बाद भी Permission denied क्यों आता है?

सबसे आम वजह redirection है। sudo command > file या sudo command >> file में file को आपका shell खोलता है, आपके अपने अधिकार से, और यह sudo के चलने से पहले होता है। इसका हल echo 'line' | sudo tee -a /path/to/file है, या पूरा command sudo sh -c '...' के अंदर रखना। अगर redirection है ही नहीं, तो रोक file mode की परत से बाहर है: lsattr से immutable attribute देखिए, findmnt -T से noexec या read-only mount देखिए, और sudo dmesg -T में DENIED शब्द खोजिए, क्योंकि ये तीनों root को भी रोकते हैं।

mode और owner दोनों सही दिख रहे हैं, फिर रोक कहाँ से आ रही है?

अक्सर रोक उस file पर होती ही नहीं, उसके रास्ते में पड़ने वाली किसी parent directory पर होती है। namei -l /path/to/file चलाइए और ऊपर से नीचे पढ़ते हुए पहली ऐसी कड़ी ढूँढिए जिसमें आप पर लागू खंड में x नहीं है, क्योंकि directory का x उसमें से आर-पार जाने का अधिकार है। दूसरी संभावना ACL है, जिसका संकेत ls -ld की mode string के आख़िर में लगा + देता है और पूरी सूची getfacl दिखाता है।

Permission denied और Operation not permitted में क्या फ़र्क़ है?

Permission denied तब आता है जब आपकी पहचान और target के अधिकार मेल नहीं खाते, यानी सही user या सही समूह होने पर वही काम चल जाता। Operation not permitted इससे अलग है: वहाँ काम इस रूप में मना है, चाहे आप कोई भी हों। immutable attribute लगी file को बदलना इसी तरह का मामला है, और वह root के लिए भी मना रहता है जब तक sudo chattr -i से attribute न हटा दिया जाए। message को शब्दशः पढ़ना इसीलिए ज़रूरी है, क्योंकि दोनों के इलाज अलग हैं।