nano সেভ হচ্ছে না: permission denied সমাধান

কেন 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 আপনার মালিকানায় সেট করা একটি অস্থায়ী কপি তৈরি করে, সেই কপিতে আপনার নিজের user হিসেবে nano চালায়, তারপর editor বন্ধ হলে root privilege ব্যবহার করে ফলাফলটি মূল অবস্থানে কপি করে। editor কখনো root হিসেবে চলে না। sudo -e ভিন্ন নামে একই command। editor নির্বাচন করা হয় প্রথমে SUDO_EDITOR, এরপর VISUAL, তারপর EDITOR থেকে। তাই আপনার shell profile-এ export EDITOR=nano সেট করলে এটি সর্বত্র default হয়ে যায়। এই variable-গুলোর কোনোটিতেই যদি বিদ্যমান এবং চালানো যায় এমন editor-এর নাম না থাকে, sudoedit sudoers-এর editor setting ব্যবহার করে; এর default হলো vi।

sudo nano-ও ফাইলটি save করে, আর সমস্যাটি সেখানেই। এটি পুরো filesystem-এর ওপর root privilege-সহ একটি পূর্ণাঙ্গ interactive editor চালায়, যতক্ষণ session চালু থাকে। ফলে save prompt-এ ভুল path লিখলে আপনার text root হিসেবে অন্য একটি system file-এর ওপর লিখে যেতে পারে। যে কাজগুলোর জন্য sudo প্রয়োজন শুধু সেগুলোর সময় sudo ব্যবহার করা একজন সাধারণ user হিসেবে কাজ করা গড়ে তোলার মতো অভ্যাস। Config file সম্পাদনার সময় sudoedit সেই অভ্যাসেরই প্রয়োগ।

sudoedit-এর দুটি rule অনেককে অবাক করে। এটি symbolic link সম্পাদনা করতে অস্বীকার করে। আপনি root না হলে, যে directory-তে আপনার write permission আছে তার ভেতরের কোনো file সম্পাদনা করতেও এটি অস্বীকার করে। দ্বিতীয় rule-টি আছে কারণ directory-তে write করতে পারে এমন যে কেউ editor খোলা থাকা অবস্থায় file-টি বদলে দিতে পারে। উভয় আচরণই sudoers-এর default (sudoedit_follow off, sudoedit_checkdir on)। এখনো বিদ্যমান নয় এমন file আপনার জন্য তৈরি করা হয়।

কারণ 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: ফাইলসিস্টেম read-only, অথবা এতে আর কোনো স্থান অবশিষ্ট নেই

findmnt-এ ro রিপোর্ট করা মানে write কখনোই সফল হওয়ার কথা ছিল না। হয় ফাইলসিস্টেমটি সেভাবেই mount করা হয়েছিল—/etc/fstab বা read-only bind mount-এর মাধ্যমে—অথবা disk error-এর পরে kernel এটিকে read-only হিসেবে পুনরায় mount করেছে। দ্বিতীয় ঘটনাটিই গুরুতর। sudo dmesg -T | tail -50 সর্বশেষ kernel message দেখায়, কিন্তু remount ঘটানোর input/output এবং filesystem error শেষ 50টি line-এর মধ্যে নাও থাকতে পারে। tail ছাড়া sudo dmesg -T চালিয়ে kernel ring buffer-এ এখনো থাকা সব message দেখুন, এবং remount-এর আগে log হওয়া error খুঁজুন। এর সমাধান হলো ফাইলসিস্টেম unmount থাকা অবস্থায় filesystem check চালানো। root ছাড়া অন্য কোনো ফাইলসিস্টেম unmount করে সেখানেই check করা যায়। root-এর ক্ষেত্রে সাধারণ boot-ও এটি করতে পারে: /etc/fstab-এ যার fsck pass number শূন্যের বেশি, systemd সেই প্রতিটি ফাইলসিস্টেম check করে; initrd সমর্থন করলে initrd-তে root check করে; এবং kernel command line-এ fsck.mode=force দিলে full check বাধ্যতামূলক হয়। VPS এত দূর পর্যন্ত boot না হলে provider-এর rescue console-ই fallback।

Full filesystem একই write-এ ভিন্ন কারণে ব্যর্থ হয়। df -h সাধারণ ঘটনাটি কভার করে। df -i এমন ঘটনাটি কভার করে যা মানুষ প্রায়ই বাদ দেয়: ext4-এ, যা সাধারণত default, inode filesystem তৈরির সময় তৈরি হওয়া একটি fixed pool থেকে আসে। ফলে ছোট ছোট file-এর একটি tree সব inode ব্যবহার করে ফেলতে পারে, যদিও df -h এখনো free gigabyte দেখায়। XFS file তৈরি হওয়ার সময় inode allocate করে, তাই এই সমস্যা মূলত ext4-এ দেখা যায়। স্থান শেষ হয়ে গেলে এবং কোনো স্পষ্ট কারণ না থাকলে, পূর্ণ disk নিয়ে df ও du-এর ফল আলাদা হওয়া সেই deleted-but-still-open file-এর বিষয়টি ব্যাখ্যা করে, যা এর কারণ হতে পারে।

এখানে একটি বিষয় বিভ্রান্তিকর লক্ষণটি ব্যাখ্যা করে। filesystem তৈরির সময় ext4 তার block-এর একটি অংশ root-এর জন্য reserve করে। তাই সাধারণ user-দের write প্রত্যাখ্যান হওয়ার পরও root write চালিয়ে যেতে পারে। তখন sudo-কে সমাধান বলে মনে হয়, disk বাকি স্থানটুকুও পূর্ণ হয়ে যায়, এবং সমস্যা আরও খারাপ রূপে ফিরে আসে।

নতুন content লেখার আগে nano file truncate করে। তাই space শেষ হয়ে গেলে মাঝপথে ব্যর্থ হওয়া write file-টিকে আগের চেয়ে ছোট করে রাখতে পারে। প্রায় পূর্ণ ফাইলসিস্টেমে কোনো গুরুত্বপূর্ণ config edit করার আগে তার একটি copy তৈরি করুন। sudo cp -a /etc/nginx/nginx.conf /root/nginx.conf.bak copy-টির owner, group এবং permissions অপরিবর্তিত রাখে।

কারণ 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 ব্যবহার করুন। এটি ফাইলটির একটি অস্থায়ী কপি তৈরি করে, যার মালিক আপনি। এরপর আপনার নিজের user হিসেবে editor চালায় এবং editor বন্ধ হলে ফলাফলটি root হিসেবে মূল ফাইলে লিখে দেয়। ফলে editor নিজে কখনও root privilege ধরে রাখে না। nano বেছে নিতে SUDO_EDITOR, VISUAL অথবা EDITOR-কে nano হিসেবে সেট করুন। sudo nano-ও কাজ করে। তবে এটি session চলাকালীন interactive editor-কে সিস্টেমের প্রতিটি path-এ root access দেয়। ফলে save prompt-এ একটি filename ভুল টাইপ করলেই system file ক্ষতিগ্রস্ত হতে পারে।

nano দিয়ে কোনো ফাইল save করতে directory-তে write permission কি প্রয়োজন?

ইতিমধ্যে থাকা ফাইলের ক্ষেত্রে নয়। nano সরাসরি ফাইলটির মধ্যেই লেখে। তাই kernel ফাইলটির write bit এবং path-এর প্রতিটি directory-র execute bit পরীক্ষা করে। ফাইলটি আগে থেকে না থাকলে directory-র write bit গুরুত্বপূর্ণ, কারণ তখন নতুন একটি নাম তৈরি করতে হয়। Backup বা file locking চালু থাকলেও এটি গুরুত্বপূর্ণ, কারণ উভয় ক্ষেত্রেই মূল ফাইলের পাশে একটি দ্বিতীয় ফাইল লেখা হয়।

মালিক সঠিক এবং disk-ও full নয়। আর কী কারণে write আটকে যেতে পারে?

চারটি সাধারণ কারণ আছে। Filesystem read only হিসেবে mount করা থাকতে পারে; findmnt -no OPTIONS -T /etc/nginx/nginx.conf তা দেখায়। ফাইলে immutable attribute থাকতে পারে; lsattr তা দেখায় এবং sudo chattr -i তা সরায়। এই attribute সেট থাকা অবস্থায় root-ও ফাইলে লিখতে পারে না। ext4-এ free space থাকা সত্ত্বেও inode pool শেষ হয়ে যেতে পারে; df -i তা দেখায়। Permission bit write অনুমোদন করলেও SELinux বা AppArmor write প্রত্যাখ্যান করতে পারে। Audit log-এ সাধারণত এই প্রত্যাখ্যান নথিভুক্ত হয়। তবে SELinux-এর dontaudit rule কোনো কিছু log না করেই write আটকে দিতে পারে। সমস্যাটি পুনরুৎপাদনের সময় sudo semodule -DB ওই rule-গুলো বন্ধ করে, আর sudo semodule -B সেগুলো আবার চালু করে।

ফাইলটি একেবারেই save না হলে পরিবর্তনগুলো কোথায় রাখব?

Ctrl-O চাপুন এবং এমন একটি path দিন যার মালিক আপনি। এটি আপনার home directory-র অধীনে হতে পারে, অথবা আপনার user যেখানে লিখতে পারে এমন অন্য কোনো স্থানেও হতে পারে। Buffer এখনও memory-তে থাকে, তাই আপনি যা টাইপ করেছেন তা হারায় না। এরপর sudo cp ব্যবহার করে saved file-টি সঠিক স্থানে copy করুন। এটি মূল ফাইলের owner ও permissions অপরিবর্তিত রাখে। তারপর service reload করার আগে service-এর নিজস্ব test command দিয়ে ফাইলটি পরীক্ষা করুন।

Docker container-এর ভেতরের আমার edit কেন হারিয়ে যায়?

Path-টি mount না হলে edit ওই container-এর writable layer-এ লেখা হয়। Container প্রতিস্থাপিত হলে সেই layer মুছে যায়। Bind mount বা volume-এর host-side-এ ফাইলটি edit করুন, অথবা image-এর মধ্যে এটি build করুন। Path-টি bind mount হওয়া সত্ত্বেও save প্রত্যাখ্যাত হলে container-এর ভেতরের id -u-এর সঙ্গে ls -ln থেকে পাওয়া numeric owner তুলনা করুন। ফাইলটি তার host ownership বজায় রাখে, তাই container process-কে সেই ownership-এর সঙ্গে মিলতে হয়।