خطای Read-only file system یعنی مسیر هدف در لایه فایل‌سیستم اجازه نوشتن نمی‌دهد؛ chmod 777 این وضعیت را تغییر نمی‌دهد. ممکن است mount عمداً ro باشد، volume کانتینر فقط‌خواندنی تنظیم شده باشد یا کرنل پس از خطای دیسک، نوشتن را برای حفاظت داده متوقف کرده باشد. پیش از remount، علت را مشخص کنید.
مسیر و نوع فایل‌سیستم را پیدا کنید
به‌جای حدس‌زدن نام دیسک، مسیر واقعی فایل مشکل‌دار را بررسی کنید. نمونه زیر برای مسیر /var/www است؛ مسیر خودتان را جایگزین کنید.
findmnt -T /var/www
lsblk -f
df -h
df -i
sudo journalctl -k -b --no-pagerکمبود فضا یا inode معمولاً پیام متفاوتی مانند No space left on device دارد. permission denied نیز می‌تواند از مالکیت، ACL یا SELinux بیاید. این موارد را با read-only یکسان نگیرید. در کانتینر، تنظیم mount میزبان و سیاست runtime نیز باید بررسی شود.
لاگ چه تصمیمی را تغییر می‌دهد؟
پیام‌های I/O error، خطای دستگاه یا ext4 journal نشانه آن است که صرف بازکردن مجدد نوشتن می‌تواند خطرناک باشد. در ext4، گزینه errors=remount-ro برای واکنش به خطای فایل‌سیستم وجود دارد. اگر داده مهم است، نوشتن اضافی و آزمایش‌های مخرب را متوقف و ابتدا امکان برداشت امن یا بازیابی از بکاپ را با مدیر ذخیره‌سازی بررسی کنید.
اگر ro عمدی بوده است
- فایل fstab، mount unit، تنظیم volume یا سیاست محیط را پیدا کنید.
- هدف فقط‌خواندنی‌بودن را روشن کنید؛ image سیستم یا رسانه محافظت‌شده ممکن است عمداً قابل نوشتن نباشد.
- فقط اگر سلامت دیسک و مجازبودن نوشتن تأیید شده، تنظیم mount همان مسیر را اصلاح کنید.
- پس از تغییر، وضعیت mount و یک آزمون محدود نوشتن در مسیر مجاز را کنترل کنید.
تعمیر فایل‌سیستم باید متناسب باشد
fsck عمومی را روی فایل‌سیستم mounted و دارای نوشتن اجرا نکنید. تعمیر ext4 و XFS ابزار و پیش‌شرط متفاوت دارند؛ دستور xfs_repair یا e2fsck را بدون شناسایی نوع، دستگاه و حالت آفلاین انتخاب نکنید. برای پارتیشن ریشه معمولاً rescue یا محیط نگهداری لازم است. نام نمونه /dev/sda1 در یک آموزش، مجوز اجرای تعمیر روی همان نام در سرور شما نیست.
چه زمانی مشکل واقعاً رفع شده است؟
- دلیل اولیه، نه فقط علامت ro، رفع یا مستند شده باشد.
- لاگ کرنل پس از بازگشت سرویس خطای تازه ذخیره‌سازی نداشته باشد.
- سلامت دیتابیس و فایل‌های برنامه با ابزار همان محصول کنترل شود.
- بکاپ قابل بازیابی و پایش دیسک برقرار باشد؛ reboot به‌تنهایی تأیید سلامت نیست.
مطالعه مرتبط
منابع و مستندات
بازبینی محتوا و منابع: ۲۶ مهر ۱۴۰۵. دستورهای نمونه برای محیط مشخص‌شده‌اند؛ پیش از استفاده روی سرویس عملیاتی، سازگاری محیط و نسخه پشتیبان را بررسی کنید.
