nano ফাইল সেভ হচ্ছে না? সমাধান ও কারণসমূহ

কেন nano আপনার ফাইল সেভ করতে পারে না

nano আপনার ফাইল সেভ করতে না পারার পেছনে চারটি কারণ থাকতে পারে: আপনার ফাইলের মালিকানা নেই, প্যারেন্ট ডিরেক্টরি nano-এর প্রয়োজনীয় কাজ করার অনুমতি দিচ্ছে না, ফাইলসিস্টেমটি read-only বা তাতে জায়গা খালি নেই, অথবা আপনি এমন একটি কন্টেইনারের ভেতর আছেন যেখানে অন্য কোনো user ID ব্যবহার করা হচ্ছে। প্রথম দুটি কারণ হলো পারমিশন সংক্রান্ত সমস্যা, আর পরের দুটি তা নয়। এই ক্রম অনুযায়ী সমস্যাগুলো যাচাই করুন, কারণ প্রথম কারণটিই অধিকাংশ ক্ষেত্রে ঘটে, এটি নিশ্চিত করতে মাত্র একটি কমান্ড লাগে এবং এর সমাধান হলো sudoedit, sudo nano নয়।

এডিটর খোলা থাকা অবস্থায় কোনো কিছুই হারিয়ে যায় না। আপনার টেক্সট মেমোরিতে জমা থাকে, তাই আপনি ফাইলটি খোলা রেখে বাফারটিকে এমন একটি পাথে সেভ করতে পারেন যার মালিকানা আপনার আছে এবং পরে সেটিকে সঠিক জায়গায় সরিয়ে নিতে পারেন। এই বিকল্প উপায়টি এই গাইডের শেষের দিকে দেওয়া হয়েছে।

কোনো পারমিশন পরিবর্তন করার আগে এই চেকগুলো চালান

প্রতিটি কমান্ডকে সেই আসল পাথের দিকে নির্দেশ করুন যা আপনি এডিট করছেন। এগুলো ভিন্ন ভিন্ন প্রশ্নের উত্তর দেয়, তাই কোনো কিছু পরিবর্তন করার আগে সবগুলো কমান্ড চালিয়ে দেখুন। কোন চেকটি ব্যর্থ হচ্ছে তা না জেনে পারমিশন পরিবর্তন করলে সাধারণত আগের সমস্যার ওপর নতুন আরেকটি সমস্যা তৈরি হয়।

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 কমান্ডটি খালি জায়গা এবং df -i কমান্ডটি খালি ইনোড (inodes) রিপোর্ট করে, কারণ ইনোড খালি হওয়া এবং ডিস্ক স্পেস খালি হওয়া দুটি ভিন্ন বিষয়। যদি এই পারমিশন স্ট্রিংগুলো আপনার পরিচিত না হয়, তবে ls -l দ্বারা প্রিন্ট করা পারমিশন স্ট্রিং কীভাবে পড়তে হয় তা দিয়ে শুরু করুন।

কারণ 1: ফাইলটির মালিক root এবং আপনি নন

পড়া এবং লেখার অনুমতি আলাদা, এবং /etc-এর অধীনে থাকা বেশিরভাগ ফাইলই সবাই পড়তে পারে। এই কারণেই nano ফাইলটি খোলে, আপনাকে বিষয়বস্তু দেখায় এবং অবাধে টাইপ করতে দেয়: এর কোনোটিই ডিস্কে কোনো পরিবর্তন করে না। ফাইলটি সংরক্ষণ করার সময় বাধা আসে, যখন kernel আপনার user ID এবং group ID-গুলোকে ফাইলের মালিক, গ্রুপ এবং অন্যান্য বিটের সাথে তুলনা করে। nano শুধুমাত্র kernel-এর দেওয়া তথ্যটি আপনাকে জানায়, তাই nano-এর কোনো অপশনই এই ফলাফল পরিবর্তন করতে পারে না।

id এবং ls -l একসাথে এই বিষয়টি নিশ্চিত করে। ফাইলটির মালিক root, আপনি root নন এবং অন্যান্য বিটগুলো আপনাকে লেখার অনুমতি দেয় না। পুনরায় Ctrl-O চাপলে কোনো লাভ হবে না।

কেন root-এর মালিকানাধীন ফাইল এডিট করার সঠিক উপায় হলো sudoedit

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

sudo ফাইলের একটি অস্থায়ী কপি তৈরি করে যার মালিকানা আপনার নামে সেট করা থাকে। এরপর আপনার নিজের ইউজার হিসেবে সেই কপির ওপর nano চালানো হয়। এডিটর বন্ধ হওয়ার পর root প্রিভিলেজ ব্যবহার করে ফাইলটি মূল জায়গায় কপি করা হয়। এডিটর কখনোই root হিসেবে চলে না। sudo -e হলো ভিন্ন নামে একই কমান্ড। এডিটর নির্বাচনের ক্ষেত্রে প্রথমে SUDO_EDITOR, তারপর VISUAL এবং সবশেষে EDITOR দেখা হয়, তাই আপনার shell profile-এ export EDITOR=nano সেট করলে সেটি সব জায়গায় ডিফল্ট হিসেবে কাজ করবে। যদি আপনার sudoers ফাইলে env_editor ফ্ল্যাগটি বন্ধ থাকে, তবে এই ভেরিয়েবলগুলো উপেক্ষা করা হয় এবং সেক্ষেত্রে sudoers-এর editor সেটিং থেকে এডিটর নির্বাচন করা হয়।

sudo nano ব্যবহার করে ফাইল সেভ করা যায়, আর এখানেই সমস্যা। এটি পুরো সেশন চলাকালীন একটি পূর্ণাঙ্গ ইন্টার‍্যাক্টিভ এডিটরকে পুরো ফাইলসিস্টেমের ওপর root প্রিভিলেজ দেয়। ফলে সেভ করার সময় ভুলবশত কোনো পাথ টাইপ করলে root হিসেবে অন্য কোনো সিস্টেম ফাইলের ওপর আপনার টেক্সট ওভাররাইট হয়ে যেতে পারে। যেসব ধাপে প্রয়োজন কেবল সেই ধাপেই sudo ব্যবহারকারী সাধারণ ইউজার হিসেবে কাজ করার অভ্যাস গড়ে তোলা জরুরি, আর কনফিগারেশন ফাইল এডিট করার সময় sudoedit ব্যবহার করা সেই অভ্যাসেরই অংশ।

sudoedit-এর দুটি নিয়ম মানুষকে অবাক করে। এটি কোনো symbolic link এডিট করতে দেয় না এবং এমন কোনো ডিরেক্টরির ভেতরের ফাইল এডিট করতে দেয় না যেখানে আপনি লিখতে পারেন, যদি না আপনি root হন। দ্বিতীয় নিয়মটি থাকার কারণ হলো, যে কেউ ডিরেক্টরিতে লিখতে পারলে এডিটর খোলা থাকা অবস্থায় ফাইলটি বদলে দিতে পারে। উভয় আচরণই sudoers-এর ডিফল্ট সেটিং (sudoedit_follow বন্ধ, sudoedit_checkdir চালু)। কোনো ফাইল আগে থেকে না থাকলে তা আপনার জন্য তৈরি করে দেওয়া হয়।

কারণ 2: প্যারেন্ট ডিরেক্টরি আসলে কী নিয়ন্ত্রণ করে

অন্যান্য এডিটরদের জন্য লেখা পরামর্শে বলা হয় যে, ফাইল সেভ করার জন্য ডিরেক্টরিতে রাইট পারমিশন প্রয়োজন। কারণ অনেক এডিটর নতুন একটি ফাইল লিখে সেটি দিয়ে পুরনো ফাইলটিকে রিনেম (rename) করে প্রতিস্থাপন করে। nano এভাবে কাজ করে না। এটি আপনার দেওয়া ফাইলটি ওপেন করে সরাসরি সেই ফাইলের ভেতরেই লেখে। তাই যদি ফাইলটি আগে থেকেই বিদ্যমান থাকে, তবে ডিরেক্টরির রাইট বিট (write bit) কখনোই যাচাই করা হয় না।

ডিরেক্টরি অন্যান্য বিষয়গুলো নিয়ন্ত্রণ করে, যে কারণে চেক লিস্টে ls -ld রাখা হয়েছে:

• নতুন কোনো ফাইল তৈরি করার জন্য ডিরেক্টরিতে রাইট এবং এক্সিকিউট পারমিশন প্রয়োজন, কারণ ডিরেক্টরিতে একটি নতুন নাম যোগ করতে হয়। আপনার umask নির্ধারণ করে নতুন ফাইলটি কী পারমিশন নিয়ে তৈরি হবে।
• কোনো ফাইল অ্যাক্সেস করার জন্য সেই ফাইলের পাথ-এ থাকা প্রতিটি ডিরেক্টরিতে এক্সিকিউট পারমিশন (যাকে সার্চ পারমিশনও বলা হয়) থাকতে হয়। কোনো একটি ডিরেক্টরিতে এই পারমিশন না থাকলে তার নিচের সবকিছু ব্লক হয়ে যায় এবং namei -l আপনাকে দেখাবে ঠিক কোথায় সমস্যাটি হচ্ছে।
• ব্যাকআপসহ সেভ করা বা ফাইল লকিং চালু থাকলে মূল ফাইলের পাশে দ্বিতীয় আরেকটি ফাইল তৈরি হয়, তাই এই ফিচারগুলোর জন্য ডিরেক্টরি রাইটেবল হওয়া প্রয়োজন। ব্যাকআপ হলো -B অপশন অথবা nanorc ফাইলের set backup, এবং লকিং হলো -G অথবা set locking। আপনি বা আপনার ডিস্ট্রিবিউশন এগুলো চালু না করলে সাধারণত এগুলো বন্ধ থাকে।

সিস্টেমের অন্যান্য জায়গাতেও ডিরেক্টরি পারমিশন একইভাবে কাজ করে। আপনার হোম ডিরেক্টরি বা .ssh ডিরেক্টরিতে অন্য ব্যবহারকারীদের রাইট পারমিশন থাকলে SSH সার্ভার কি (key) গ্রহণ করতে অস্বীকার করে। এটি লগইনের সময় SSH কর্তৃক কি প্রত্যাখ্যান করার একটি সাধারণ কারণ।

যেহেতু nano সরাসরি বিদ্যমান ফাইলে লেখে, তাই ফাইলটি তার inode বজায় রাখে, যা ফাইলের নামের পেছনে থাকা অন-ডিস্ক পরিচয়। ফাইলটি ওপেন করে রাখা যেকোনো প্রসেস সেটিকে ট্র্যাক করতে পারে এবং কন্টেইনারে bind mount করা একটি ফাইলও কাজ চালিয়ে যেতে পারে। যে এডিটরগুলো ফাইল প্রতিস্থাপনের মাধ্যমে সেভ করে, সেগুলো এই মাউন্ট ভেঙে ফেলে, কারণ মাউন্টটি ফাইলের নামের পরিবর্তে inode অনুসরণ করে।

কারণ 3: ফাইলসিস্টেমটি রিড-অনলি মোডে আছে, অথবা এতে আর কোনো জায়গা অবশিষ্ট নেই

findmnt অপশনে ro রিপোর্ট করার অর্থ হলো রাইট অপারেশনটি সফল হওয়ার কোনো সম্ভাবনা ছিল না। হয় ফাইলসিস্টেমটি /etc/fstab-এর মাধ্যমে অথবা রিড-অনলি বাইন্ড মাউন্ট হিসেবে সেভাবে মাউন্ট করা হয়েছে, অথবা ডিস্ক ত্রুটির কারণে কার্নেল এটিকে রিড-অনলি মোডে রিমাউন্ট করেছে। দ্বিতীয় ক্ষেত্রটি বেশ গুরুতর। sudo dmesg -T | tail -50 ইনপুট/আউটপুট এবং ফাইলসিস্টেমের সেই ত্রুটিগুলো দেখায় যার কারণে রিমাউন্ট হয়েছে; এর সমাধান হলো ফাইলসিস্টেমটি আনমাউন্ট করে একটি ফাইলসিস্টেম চেক চালানো, যা একটি VPS-এর ক্ষেত্রে প্রোভাইডারের রেসকিউ কনসোল থেকে বুট করার মাধ্যমে করতে হয়।

ফাইলসিস্টেম পূর্ণ হয়ে গেলে ভিন্ন কারণে একই রাইট অপারেশন ব্যর্থ হয়। df -h সাধারণ ক্ষেত্রটি কভার করে। df -i সেই ক্ষেত্রটি কভার করে যা মানুষ প্রায়ই এড়িয়ে যায়: ফাইলসিস্টেম তৈরির সময় একটি নির্দিষ্ট পুল থেকে ইনোড (inodes) তৈরি হয়। অনেকগুলো ছোট ফাইলের একটি ট্রি সব ইনোড ব্যবহার করে ফেলতে পারে, যদিও df -h তখনো গিগাবাইট পরিমাণ জায়গা খালি দেখায়। যখন জায়গা শেষ হয়ে যায় এবং কোনো কিছু জায়গা দখল করে আছে বলে মনে হয় না, তখন df এবং du-এর ডিস্ক পূর্ণ হওয়ার তথ্যে অমিল বিষয়টি দেখুন, যা ডিলিট করা কিন্তু ওপেন থাকা ফাইলের কারণে সৃষ্ট সমস্যাটি ব্যাখ্যা করে।

একটি বিষয় এখানে বিভ্রান্তিকর লক্ষণটি ব্যাখ্যা করে। ext4 ফাইলসিস্টেম তৈরির সময় রুট (root)-এর জন্য ব্লকের একটি অংশ সংরক্ষিত রাখে, তাই সাধারণ ব্যবহারকারীদের বাধা দেওয়ার পরেও রুট লিখতে পারে। sudo তখন সমাধান মনে হতে পারে, কিন্তু ডিস্ক বাকি অংশটুকুও পূর্ণ করে ফেলে এবং সমস্যাটি আরও খারাপ আকারে ফিরে আসে।

যেহেতু nano নতুন কন্টেন্ট লেখার আগে ফাইলটিকে ট্রাঙ্কেট (truncate) করে, তাই রাইট অপারেশন মাঝপথে জায়গা শেষ হয়ে গেলে ফাইলটি আগের চেয়ে ছোট হয়ে যেতে পারে। প্রায় পূর্ণ হয়ে যাওয়া ফাইলসিস্টেমে কোনো গুরুত্বপূর্ণ কনফিগারেশন ফাইল এডিট করার আগে সেটির একটি কপি রাখুন। sudo cp -a /etc/nginx/nginx.conf /root/nginx.conf.bak কপির ক্ষেত্রে মালিকানা (owner), গ্রুপ এবং পারমিশন ঠিক রাখে।

কারণ 4: আপনি একটি কন্টেইনারের ভেতরে bind mount এডিট করছেন

ফাইলের মালিকানা সংখ্যাসূচক (numeric)। কার্নেল একটি ইউজার আইডি সংরক্ষণ করে এবং আপনি যে নামটি দেখেন তা নির্ভর করে কোন /etc/passwd ফাইলটি লুকআপ করছে তার ওপর। তাই একটি ফাইল হোস্ট মেশিনে এক নামে এবং কন্টেইনারের ভেতরে অন্য নামে বা শুধুমাত্র একটি সংখ্যা হিসেবে দেখা যেতে পারে। নামের পরিবর্তে সংখ্যাগুলো তুলনা করুন: কন্টেইনারের ভেতরে id -u এবং ফাইলের ওপর ls -ln কমান্ডটি চালান।

একটি bind mounted ফাইল হোস্ট মেশিনে যে মালিকানায় থাকে, কন্টেইনারের ভেতরেও সেই মালিকানাই বজায় রাখে। যখন হোস্টের ফাইলটি আপনার ইউজারের অধীনে থাকে কিন্তু কন্টেইনারের প্রসেস অন্য কোনো ইউজারের অধীনে চলে, তখন কন্টেইনারের ভেতরে রাইট করার অনুমতি প্রত্যাখ্যান করা হয় এবং কন্টেইনারের ভেতরের sudo হোস্টের ফাইলের মালিক পরিবর্তন করতে পারে না। এটি ঠিক করতে হোস্ট থেকে ফাইলের মালিকানা পরিবর্তন করে কন্টেইনারের প্রসেস যে আইডিতে চলছে তাতে সেট করুন, অথবা কন্টেইনারটিকে সেই আইডিতে চালান যার অধীনে ফাইলগুলো আগে থেকেই আছে। linuxserver.io এবং অনুরূপ প্রজেক্টের ইমেজগুলো PUID এবং PGID ভেরিয়েবলগুলো প্রকাশ করে যা নির্ধারণ করে প্রসেসটি কোন ইউজারের অধীনে চলবে।

কন্টেইনারের আরও দুটি ক্ষেত্র জেনে রাখা ভালো। :ro দিয়ে read-only করা মাউন্ট বা --read-only দিয়ে শুরু করা কন্টেইনার মালিকানা যাই হোক না কেন রাইট করার অনুমতি দেয় না এবং কন্টেইনারের ভেতরের cat /proc/mounts এই ফ্ল্যাগটি প্রদর্শন করে। rootless Podman-এর ক্ষেত্রে, একটি ইউজার নেমস্পেস কন্টেইনারের ইউজার আইডিগুলোকে হোস্টের আইডিগুলোর একটি রেঞ্জে ম্যাপ করে। ফলে কন্টেইনারের ভেতরে যে ফাইলটি root-এর বলে মনে হয়, সেটি বাইরে আপনার আনপ্রিভিলেজড অ্যাকাউন্টের অধীনে থাকে।

এছাড়াও এমন এডিট আছে যা সফল হয় কিন্তু পরে হারিয়ে যায়। কন্টেইনারের ভেতরে এমন কোনো পাথে ফাইল পরিবর্তন করলে যা মাউন্ট করা নয়, সেটি কন্টেইনারের writable লেয়ারে থাকে এবং কন্টেইনারটি পুনরায় তৈরি করা হলে সেই লেয়ারটি মুছে যায়। পরিবর্তনটি স্থায়ী করতে চাইলে মাউন্টের হোস্ট সাইডে অথবা ইমেজ বিল্ড করার সময় ফাইলটি পরিবর্তন করুন।

এস্কেপ হ্যাচ: আপনার মালিকানাধীন একটি পাথে সেভ করুন

এডিটরের ভেতর থেকে প্রিভিলেজ পাওয়ার চেষ্টা করবেন না। 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 ব্যবহার করুন। এটি ফাইলটিকে আপনার মালিকানাধীন একটি অস্থায়ী কপিতে রূপান্তর করে, আপনার নিজস্ব ইউজার হিসেবে এডিটর চালায় এবং এডিটর বন্ধ হওয়ার পর রুট হিসেবে ফলাফলটি মূল ফাইলে লিখে দেয়। ফলে এডিটরটি কখনোই রুট প্রিভিলেজ ধারণ করে না। nano বেছে নিতে SUDO_EDITOR, VISUAL অথবা EDITOR-কে nano হিসেবে সেট করুন। sudo nano-ও কাজ করে, তবে এটি সেশনের পুরো সময় জুড়ে একটি ইন্টারঅ্যাক্টিভ এডিটরকে সিস্টেমের প্রতিটি পাথে রুট অ্যাক্সেস দিয়ে দেয়। এর ফলে সেভ করার সময় ফাইলের নাম ভুল টাইপ করলে সিস্টেম ফাইল ক্ষতিগ্রস্ত হতে পারে।

nano দিয়ে ফাইল সেভ করার জন্য ডিরেক্টরিতে কি আমার রাইট পারমিশন থাকা প্রয়োজন?

বিদ্যমান ফাইলের ক্ষেত্রে প্রয়োজন নেই। nano সরাসরি ফাইলের ভেতরেই লেখে, তাই কার্নেল ফাইলের রাইট বিট এবং ফাইলের পাথে থাকা প্রতিটি ডিরেক্টরির এক্সিকিউট বিট চেক করে। ডিরেক্টরির রাইট বিট তখনই গুরুত্বপূর্ণ যখন ফাইলটি আগে থেকে থাকে না, কারণ তখন নতুন নাম তৈরি করতে হয়। এছাড়া ব্যাকআপ বা ফাইল লকিং চালু থাকলে ডিরেক্টরির রাইট পারমিশন প্রয়োজন হয়, কারণ এগুলো মূল ফাইলের পাশে দ্বিতীয় একটি ফাইল তৈরি করে।

ফাইলের মালিকানা ঠিক আছে এবং ডিস্কও পূর্ণ নয়। আর কী কারণে রাইট করা বাধাগ্রস্ত হতে পারে?

চারটি কারণ থাকতে পারে। ফাইলসিস্টেমটি রিড-অনলি মোডে মাউন্ট করা থাকতে পারে, যা findmnt -no OPTIONS -T /etc/nginx/nginx.conf কমান্ডে দেখা যায়। ফাইলে ইমিউটেবল অ্যাট্রিবিউট থাকতে পারে, যা lsattr দিয়ে দেখা যায় এবং sudo chattr -i দিয়ে সরানো যায়; এটি সেট করা থাকলে রুটও ফাইলে লিখতে পারে না। ডিস্কে জায়গা থাকা সত্ত্বেও ইনোড (inode) পুল শেষ হয়ে যেতে পারে, যা df -i দিয়ে দেখা যায়। পারমিশন বিট অনুমতি দিলেও SELinux বা AppArmor রাইট করা আটকে দিতে পারে; অডিট লগে আপনার চেষ্টা করা পাথের বিপরীতে এই অস্বীকৃতির রেকর্ড থাকে।

ফাইলটি কোনোভাবেই সেভ না হলে আমার পরিবর্তনগুলো কোথায় রাখব?

Ctrl-O চাপুন এবং আপনার মালিকানাধীন কোনো পাথ দিন, যেমন আপনার হোম ডিরেক্টরি বা অন্য কোনো জায়গা যেখানে আপনার রাইট করার অনুমতি আছে। বাফারটি মেমোরিতেই থাকে, তাই আপনার টাইপ করা কোনো কিছু হারাবে না। এরপর sudo cp ব্যবহার করে সেভ করা ফাইলটি সঠিক জায়গায় কপি করুন, যা মূল ফাইলের মালিকানা ও পারমিশন বজায় রাখে। সার্ভিসটি রিলোড করার আগে সংশ্লিষ্ট সার্ভিসের নিজস্ব টেস্ট কমান্ড দিয়ে ফাইলটি যাচাই করে নিন।

Docker কন্টেইনারের ভেতরে করা আমার এডিটগুলো কেন হারিয়ে যায়?

পাথটি যদি মাউন্ট করা না থাকে, তবে এডিটটি কন্টেইনারের রাইটেবল লেয়ারে জমা হয় এবং কন্টেইনারটি রিপ্লেস করা হলে সেই লেয়ারটি মুছে যায়। বাইন্ড মাউন্ট বা ভলিউমের হোস্ট সাইডে ফাইলটি এডিট করুন অথবা ইমেজ তৈরির সময় সেটি অন্তর্ভুক্ত করুন। যদি পাথটি বাইন্ড মাউন্ট করা থাকে এবং সেভ করতে বাধা দেয়, তবে কন্টেইনারের ভেতরের id -u-এর সাথে ls -ln থেকে প্রাপ্ত সংখ্যাসূচক মালিকানা তুলনা করে দেখুন: ফাইলটি তার হোস্ট মালিকানা বজায় রাখে এবং কন্টেইনারের প্রসেসকে অবশ্যই তার সাথে মিল থাকতে হয়।