Amir Jabbari
اگر هنگام ساخت، ویرایش یا حذف یک فایل در لینوکس با خطایی شبیه Read-only file system روبه‌رو شده‌اید، معنی آن معمولاً این است که فایل‌سیستمی که مسیر موردنظر روی آن قرار دارد با حالت فقط‌خواندنی یا ro Mount شده است. این وضعیت گاهی عمداً تنظیم شده، اما در سرورها بیشتر اوقات بعد از خطای فایل‌سیستم، مشکل دیسک، خطای I/O یا یک Mount اشتباه دیده می‌شود.
پاسخ کوتاه: اول با findmnt و لاگ‌های کرنل مشخص کنید فایل‌سیستم واقعاً Read-only شده یا نه. اگر هیچ خطای دیسک یا فایل‌سیستم وجود ندارد، می‌توان آن را با mount -o remount,rw دوباره قابل‌نوشتن کرد. اگر خطاهایی مثل I/O error، EXT4-fs error یا خرابی Journal دیده می‌شود، ابتدا باید فایل‌سیستم را در حالت امن تعمیر کنید؛ صرفاً Remount کردن کافی نیست.
خطای Read-only File System در لینوکس یعنی چه؟
در لینوکس هر پارتیشن یا فایل‌سیستم هنگام استفاده در یک مسیر Mount می‌شود. فایل‌سیستم می‌تواند در یکی از دو حالت اصلی قرار داشته باشد:
- rw: خواندن و نوشتن مجاز است.
- ro: فقط خواندن مجاز است و تغییر فایل‌ها امکان‌پذیر نیست.
برای مثال اگر بخواهید داخل یک فایل‌سیستم فقط‌خواندنی فایلی ایجاد کنید، ممکن است این پیام را ببینید:
touch: cannot touch 'test.txt': Read-only file systemاین خطا با Permission denied فرق دارد. در خطای Permission معمولاً مجوز کاربر یا مالکیت فایل مشکل دارد، اما در Read-only File System خود فایل‌سیستم اجازه نوشتن نمی‌دهد.
مرحله اول: مشخص کنید کدام فایل‌سیستم Read-only شده است
قبل از اجرای هر دستور تعمیر، باید بفهمید مسیر مشکل‌دار روی کدام پارتیشن قرار دارد.
فرض کنید خطا هنگام نوشتن در مسیر زیر رخ داده است:
/var/www/exampleدستور زیر را اجرا کنید:
findmnt -T /var/www/exampleخروجی ممکن است چیزی شبیه این باشد:
TARGET SOURCE FSTYPE OPTIONS
/ /dev/vda1 ext4 ro,relatimeوجود ro در ستون OPTIONS یعنی فایل‌سیستم فقط‌خواندنی است.
اگر مشکل مربوط به روت سرور است، این دستور ساده‌تر است:
findmnt /برای دیدن همه دیسک‌ها، نوع فایل‌سیستم و UUID آن‌ها نیز می‌توانید اجرا کنید:
lsblk -fمرحله دوم: قبل از Remount کردن، لاگ‌های کرنل را بررسی کنید
این مهم‌ترین مرحله عیب‌یابی است. در بسیاری از سرورها کرنل وقتی خرابی فایل‌سیستم یا خطای جدی ورودی/خروجی تشخیص دهد، برای جلوگیری از آسیب بیشتر فایل‌سیستم را Read-only می‌کند.
ابتدا اجرا کنید:
dmesg -T | tail -n 100روی سیستم‌های مبتنی بر systemd می‌توانید لاگ کرنل بوت فعلی را هم ببینید:
journalctl -k -b -p warning..alertبه پیام‌هایی شبیه موارد زیر دقت کنید:
EXT4-fs error
Buffer I/O error
I/O error
Aborting journal
Remounting filesystem read-only
blk_update_request
critical medium errorنکته مهم: اگر خطای I/O، خرابی Journal یا خطای دیسک مشاهده می‌کنید، مستقیم سراغ mount -o remount,rw نروید. ابتدا از داده‌های مهم بکاپ بگیرید و علت خرابی را مشخص کنید.
مرحله سوم: فضای دیسک و Inodeها را نیز بررسی کنید
پرشدن دیسک معمولاً خطای No space left on device ایجاد می‌کند، نه Read-only File System؛ با این حال در زمان عیب‌یابی بهتر است این مورد هم بررسی شود.
df -hسپس تعداد Inodeهای آزاد را بررسی کنید:
df -iاگر درصد استفاده در ستون Use% برابر ۱۰۰٪ باشد، ابتدا باید فضای لازم را آزاد کنید.
روش سریع: Remount کردن فایل‌سیستم به حالت Read/Write
اگر لاگ‌ها هیچ خطای جدی نشان نمی‌دهند و می‌دانید فایل‌سیستم به اشتباه با حالت ro Mount شده است، می‌توانید آن را دوباره با حالت قابل‌نوشتن Mount کنید.
برای فایل‌سیستم روت:
sudo mount -o remount,rw /سپس نتیجه را بررسی کنید:
findmnt -no OPTIONS /اگر در خروجی rw مشاهده شد، فایل‌سیستم دوباره قابل نوشتن است.
برای یک Mount Point دیگر، مثلاً /data:
sudo mount -o remount,rw /dataهشدار: اگر Remount با خطا شکست خورد یا فایل‌سیستم دوباره سریعاً Read-only شد، دستور را مرتب تکرار نکنید. این رفتار معمولاً نشانه مشکل جدی‌تری در فایل‌سیستم یا Storage است.
بررسی فایل /etc/fstab
فایل /etc/fstab مشخص می‌کند پارتیشن‌ها هنگام بوت با چه تنظیماتی Mount شوند. اگر گزینه ro داخل آن قرار گرفته باشد، فایل‌سیستم ممکن است بعد از هر ریبوت دوباره فقط‌خواندنی شود.
ابتدا یک نسخه پشتیبان بسازید:
sudo cp /etc/fstab /etc/fstab.backupسپس فایل را مشاهده کنید:
cat /etc/fstabنمونه‌ای از یک ورودی معمول:
UUID=xxxx-xxxx / ext4 defaults 0 1اگر در بخش Optionها به‌صورت صریح ro تنظیم شده باشد، باید علت آن را بررسی کنید. تغییر کورکورانه این گزینه توصیه نمی‌شود، چون ممکن است سرور عمداً با Root File System فقط‌خواندنی تنظیم شده باشد.
برای بررسی خطاهای نحوی fstab می‌توانید از دستور زیر استفاده کنید:
sudo findmnt --verifyاگر فایل‌سیستم ext4 است: تعمیر با fsck یا e2fsck
در بسیاری از سرورهای Ubuntu و Debian از فایل‌سیستم ext4 استفاده می‌شود. اگر فایل‌سیستم به‌دلیل خطا Read-only شده باشد، ممکن است نیاز به بررسی و تعمیر داشته باشد.
اول نوع فایل‌سیستم و Device را پیدا کنید:
findmnt /
lsblk -fممکن است Device روت چیزی مانند /dev/vda1، /dev/sda2 یا یک Logical Volume باشد.
خیلی مهم: نام پارتیشن را از روی نمونه‌های این مقاله حدس نزنید. دستور تعمیر باید دقیقاً روی Device واقعی سرور خودتان اجرا شود.
برای ext2، ext3 و ext4 ابزار e2fsck استفاده می‌شود. این ابزار را نباید روی فایل‌سیستم فعال و قابل‌نوشتن اجرا کرد.
اگر پارتیشن جداگانه‌ای مانند /data دارید، ابتدا آن را Unmount کنید:
sudo umount /dataبعد، با Device واقعی آن را بررسی کنید:
sudo e2fsck -f /dev/vdb1گزینه -f باعث می‌شود حتی اگر فایل‌سیستم ظاهراً Clean باشد بررسی انجام شود.
اگر مشکل مربوط به پارتیشن روت / است، نمی‌توانید آن را در یک سیستم در حال استفاده به‌سادگی Unmount کنید. در این حالت باید از یکی از روش‌های زیر استفاده شود:
- Recovery Mode در سیستم فیزیکی یا ماشین مجازی؛
- Rescue Mode ارائه‌دهنده VPS؛
- بوت از Live Linux در سیستم فیزیکی؛
- اتصال دیسک به یک سیستم دیگر در محیط مجازی.
بعد از ورود به محیط Rescue و اطمینان از Mount نبودن پارتیشن، دستور را روی Device واقعی اجرا کنید.
اگر فایل‌سیستم XFS است چه کنیم؟
برای XFS نباید انتظار داشته باشید دستور عمومی fsck.xfs فایل‌سیستم را تعمیر کند؛ این فرمان عملاً عملیات تعمیر انجام نمی‌دهد. ابزار مخصوص XFS، فرمان xfs_repair است.
اول نوع فایل‌سیستم را چک کنید:
lsblk -fبرای بررسی بدون اعمال تغییر:
sudo xfs_repair -n /dev/vdb1اگر لازم است تعمیر واقعی انجام شود، فایل‌سیستم باید Unmount باشد:
sudo umount /data
sudo xfs_repair /dev/vdb1گزینه -L در xfs_repair لاگ XFS را صفر می‌کند و می‌تواند باعث از دست‌رفتن تغییرات متادیتا یا حتی داده شود. این گزینه را فقط به‌عنوان آخرین راه و بعد از تهیه بکاپ یا Snapshot در نظر بگیرید.
اگر فایل‌سیستم Btrfs است
در Btrfs رویکرد تعمیر متفاوت است. ابتدا اطلاعات وضعیت دستگاه‌ها را بررسی کنید:
sudo btrfs device stats /برای بررسی ساختار فایل‌سیستم، ابزار btrfs check وجود دارد؛ حالت پیش‌فرض آن تغییری روی دیسک ایجاد نمی‌کند:
sudo btrfs check --readonly /dev/nvme0n1p2هشدار Btrfs: گزینه --repair را برای امتحان کردن اجرا نکنید. مستندات رسمی Btrfs نیز توصیه می‌کند این گزینه فقط با راهنمایی فرد باتجربه و بعد از پذیرش ریسک خرابی بیشتر استفاده شود.
رفع Read-only File System روی VPS
در سرور مجازی، علاوه بر خود سیستم‌عامل باید احتمال مشکل Storage میزبان را هم در نظر گرفت. اگر در dmesg خطاهای مکرر I/O دیده می‌شود، ممکن است مشکل از لایه ذخیره‌سازی زیرساخت باشد و از داخل VPS قابل رفع نباشد.
برای بررسی سریع:
dmesg -T | grep -Ei 'error|ext4|xfs|btrfs|i/o|buffer|nvme|scsi'اگر فایل‌سیستم روت Read-only شده و نیاز به fsck دارد، بهترین روش استفاده از Rescue Mode یا کنسول مدیریتی سرویس‌دهنده است؛ چون پارتیشن روت در حالت عادی در حال استفاده است.
برای اجرای سرویس‌های لینوکسی روی زیرساخت داخل ایران
اگر برای وب‌سرور، Docker، دیتابیس یا سرویس‌های لینوکسی به VPS نیاز دارید، می‌توانید پلن‌های خرید سرور مجازی ایران ایرانیکاسرور را بررسی کنید. در انتخاب سرور، فضای دیسک، نوع workload و نیاز به Snapshot یا بکاپ را متناسب با سرویس خود در نظر بگیرید.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
اگر خطا داخل Docker رخ می‌دهد
گاهی سیستم میزبان سالم است اما فقط داخل کانتینر خطای Read-only File System مشاهده می‌شود. در این حالت ممکن است Volume یا Bind Mount عمداً با حالت ro تعریف شده باشد.
Mountهای کانتینر را بررسی کنید:
docker inspect CONTAINER_NAMEدر Docker Compose نیز چنین تنظیمی باعث فقط‌خواندنی شدن Volume می‌شود:
volumes:
- ./data:/app/data:roدر صورت نیاز به نوشتن و اگر از نظر امنیتی مشکلی ندارد، باید :ro حذف یا به تنظیم مناسب تغییر داده شود.
همچنین اگر گزینه زیر در Compose فعال شده باشد، Root Filesystem کانتینر عمداً فقط‌خواندنی است:
read_only: trueبررسی سلامت دیسک در سرور فیزیکی
اگر سرور فیزیکی دارید و خطاهای I/O مشاهده می‌شود، سلامت دیسک را نیز بررسی کنید. برای دیسک‌های SATA/SAS معمولاً ابزار smartctl کاربرد دارد.
در Ubuntu و Debian:
sudo apt update
sudo apt install smartmontoolsسپس برای مثال:
sudo smartctl -a /dev/sdaروی VPS معمولاً اطلاعات SMART دیسک فیزیکی در اختیار ماشین مجازی قرار نمی‌گیرد؛ بنابراین نبود اطلاعات SMART در VPS الزاماً نشانه مشکل نیست.
ترتیب پیشنهادی برای رفع مشکل بدون ریسک اضافی
- مسیر مشکل‌دار را با
findmnt -Tبررسی کنید. - نوع فایل‌سیستم را با
lsblk -fمشخص کنید. - لاگ‌های
dmesgوjournalctlرا برای خطای I/O یا فایل‌سیستم بخوانید. - اگر اطلاعات مهم دارید، قبل از تعمیر Snapshot یا Backup بگیرید.
- اگر هیچ خطای جدی وجود ندارد و Mount اشتباه است،
remount,rwانجام دهید. - اگر ext4 خراب است، فایل‌سیستم را در Rescue Mode با
e2fsckبررسی کنید. - برای XFS از
xfs_repairو برای Btrfs از ابزارهای مخصوص خودش استفاده کنید. - بعد از تعمیر، دوباره لاگ‌ها و قابلیت نوشتن روی فایل‌سیستم را تست کنید.
چطور مطمئن شویم مشکل برطرف شده است؟
ابتدا وضعیت Mount را بررسی کنید:
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /بعد یک فایل موقت بسازید:
sudo touch /tmp/read-write-test
ls -l /tmp/read-write-test
sudo rm /tmp/read-write-testدر مرحله آخر دوباره لاگ‌های کرنل را بررسی کنید تا مطمئن شوید خطای جدیدی ثبت نشده است:
dmesg -T | tail -n 50Rollback؛ اگر تغییرات مشکل را بدتر کرد چه کنیم؟
اگر فایل /etc/fstab را تغییر داده‌اید و بعد از آن مشکل ایجاد شده، نسخه پشتیبان را برگردانید:
sudo cp /etc/fstab.backup /etc/fstabاگر فایل‌سیستم بعد از Remount مجدداً Read-only شد، آن را نشانه حل نشدن مشکل بدانید و قبل از هر تعمیر بیشتر، از داده‌ها Snapshot یا Backup تهیه کنید.
در VPSهایی که سیستم‌عامل بوت نمی‌شود، Rescue Mode معمولاً امن‌ترین محیط برای بررسی پارتیشن روت است.
اگر به محیط Rescue یا دستورات فایل‌سیستم آشنا نیستید
اجرای fsck یا ابزارهای تعمیر روی Device اشتباه می‌تواند باعث آسیب به اطلاعات شود. قبل از تعمیر دیسک سرور، از داده‌های مهم نسخه پشتیبان تهیه کنید و در صورت نیاز از سرویس کانفیگ و پشتیبانی فنی سرور استفاده کنید.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
اشتباه‌های رایج هنگام رفع Read-only File System
- اجرای فوری
fsckروی پارتیشن روت در حال استفاده؛ - فرض کردن اینکه هر فایل‌سیستم با
fsckیکسان تعمیر می‌شود؛ - استفاده از
xfs_repair -Lبدون بررسی ریسک از دست‌رفتن داده؛ - اجرای
btrfs check --repairصرفاً برای امتحان؛ - نادیده گرفتن پیام‌های I/O در
dmesg؛ - تغییر
/etc/fstabبدون تهیه نسخه پشتیبان؛ - اشتباه گرفتن Read-only File System با مشکل Permission یا مالکیت فایل؛
- Remount مداوم یک فایل‌سیستم خراب بدون رفع علت اصلی.
سؤالات متداول
آیا دستور mount -o remount,rw / همیشه خطای Read-only File System را رفع می‌کند؟
خیر. این دستور فقط زمانی مناسب است که فایل‌سیستم سالم باشد و به اشتباه یا به‌صورت موقت Read-only شده باشد. اگر کرنل به‌دلیل خرابی فایل‌سیستم یا خطای I/O آن را Read-only کرده باشد، باید علت اصلی برطرف شود.
برای ext4 از fsck استفاده کنیم یا e2fsck؟
e2fsck ابزار اختصاصی خانواده ext2/ext3/ext4 است. دستور عمومی fsck نیز بسته به نوع فایل‌سیستم ابزار مناسب را فراخوانی می‌کند. مهم‌تر از نام فرمان این است که فایل‌سیستم هنگام تعمیر فعال و قابل‌نوشتن نباشد.
آیا می‌توان روی پارتیشن روت در حال اجرا fsck زد؟
برای تعمیر عادی فایل‌سیستم روت بهتر است وارد Recovery یا Rescue Mode شوید تا پارتیشن موردنظر در حالت فعال و قابل‌نوشتن نباشد. اجرای تعمیر روی فایل‌سیستم در حال استفاده می‌تواند خطرناک باشد.
اگر فایل‌سیستم XFS باشد چه دستوری باید بزنیم؟
برای XFS ابزار اصلی تعمیر xfs_repair است. دستور fsck.xfs مانند fsck برای ext4 فایل‌سیستم را تعمیر نمی‌کند.
آیا پر بودن دیسک باعث Read-only File System می‌شود؟
پرشدن دیسک معمولاً پیام No space left on device ایجاد می‌کند. با این حال بررسی فضای آزاد و Inodeها جزو مراحل عیب‌یابی است، چون کمبود فضا می‌تواند باعث اختلال سرویس‌ها و مشکلات جانبی شود.
چرا VPS بعد از مدتی دوباره Read-only می‌شود؟
اگر پس از Remount مشکل برمی‌گردد، احتمال خرابی فایل‌سیستم، خطای I/O یا مشکل Storage وجود دارد. لاگ‌های کرنل را بررسی کنید و در صورت مشاهده خطاهای مکرر ذخیره‌سازی، موضوع را با ارائه‌دهنده VPS پیگیری کنید.
جمع‌بندی: برای رفع Read-only File System ابتدا مشخص کنید فایل‌سیستم واقعاً با حالت ro Mount شده یا خیر. بعد لاگ‌های کرنل را بررسی کنید. اگر خطای سخت‌افزاری یا خرابی فایل‌سیستم وجود ندارد، Remount به حالت rw می‌تواند کافی باشد؛ اما در صورت خرابی ext4، XFS یا Btrfs باید ابزار مخصوص همان فایل‌سیستم را در شرایط امن استفاده کنید. در سرورهای مجازی، تکرار خطای I/O می‌تواند به زیرساخت Storage میزبان مربوط باشد.
دیدگاه‌ها (۰)