خطای Read-only file system در لینوکس؛ چطور بدون آسیب بیشتر مشکل را پیدا کنیم؟

می‌خواهید فایلی ذخیره کنید یا بسته‌ای نصب کنید، اما لینوکس پیام Read-only file system می‌دهد. معنی آن این است که مسیر موردنظر در آن لحظه اجازه نوشتن از طریق فایل‌سیستم مربوط را نمی‌دهد. این حالت ممکن است عمدی باشد؛ مثلاً یک تصویر یا پشتیبان برای خواندن باز شده باشد. در شرایط دیگر، خطای دیسک یا فایل‌سیستم باعث شده سیستم برای محدودکردن آسیب، آن را فقط‌خواندنی کند.

در این راهنما قبل از هر دستور تغییر‌دهنده، مسیر و علت را مشخص می‌کنیم. اجرای فوری fsck روی فایل‌سیستم در حال استفاده یا اجبار بی‌برنامه به حالت نوشتنی می‌تواند آسیب بیشتری ایجاد کند. اگر داده مهم دارید یا خطای ورودی‌وخروجی می‌بینید، نسخه پشتیبان و وضعیت ذخیره‌سازی را پیش از تعمیر در نظر بگیرید.

متن دقیق خطا، مسیر فایل و زمانی را که مشکل شروع شد یادداشت کنید. این پیام‌ها یکسان نیستند:

| پیام | معنی اولیه و مسیر بررسی | | --- | --- | | Read-only file system | فایل‌سیستم مربوط به مسیر نمی‌پذیرد که روی آن نوشته شود؛ وضعیت mount و علت آن را بررسی کنید. | | Permission denied | معمولاً حساب یا مجوز دسترسی کافی ندارد؛ این پیام به‌تنهایی فایل‌سیستم فقط‌خواندنی را ثابت نمی‌کند. | | No space left on device | ممکن است فضا یا inode تمام شده باشد؛ مقدار هر دو را بررسی کنید. | | Input/output error | خواندن یا نوشتن در مسیر ذخیره‌سازی با خطا مواجه شده؛ ممکن است سخت‌افزار، شبکه ذخیره‌سازی یا فایل‌سیستم درگیر باشد. |

اگر فقط یک مسیر مشکل دارد، لازم نیست فرض کنید کل سرور فقط‌خواندنی است. اگر / یا /var دچار مشکل است، نصب بسته، ثبت لاگ، سایت و پایگاه داده هم ممکن است تحت تأثیر قرار بگیرند.

با حساب مجاز از SSH یا کنسول ارائه‌دهنده وارد همان سرور شوید. شناسه و IP را با پنل تطبیق دهید تا روی ماشین اشتباه کار نکنید. اگر اتصال SSH یا سیستم‌عامل پایدار نیست، کنسول مستقل یا محیط بازیابی ارائه‌دهنده را در دسترس داشته باشید.

آخرین نسخه پشتیبان مستقل و زمان آن را مشخص کنید. اگر نشانه خرابی دیسک یا تعداد زیاد خطاهای I/O دارید، کپی‌گرفتن سنگین، اسکن مکرر و تعمیر عجولانه ممکن است وضعیت را بدتر کند. درباره گرفتن تصویر یا نسخه مناسب از دیسک با مسئول ذخیره‌سازی و ارائه‌دهنده تصمیم بگیرید. برای پایگاه داده فعال، کپی فایل‌ها بدون هماهنگی و بدون درنظرگرفتن سازگاری داده الزاماً بکاپ قابل بازیابی نیست.

در ترمینال، مسیر نمونه زیر را با پوشه واقعی خطادار جایگزین کنید. مسیر باید وجود داشته باشد؛ اگر نام فایل وجود ندارد، از پوشه والد موجود آن استفاده کنید:

این دستور فقط اطلاعات فایل‌سیستمی را نشان می‌دهد که آن مسیر روی آن قرار گرفته است. TARGET محل اتصال، SOURCE دستگاه یا منبع، FSTYPE نوع فایل‌سیستم و OPTIONS گزینه‌های اتصال‌اند. مثلاً خروجی فرضی ممکن است چنین باشد:

در این مثال /data به منبع /dev/vdb1 متصل است و ro یعنی به‌صورت فقط‌خواندنی متصل شده است. اگر rw می‌بینید، همان فایل‌سیستم در فهرست اتصال نوشتنی گزارش شده و باید مسیر دقیق خطا، کانتینر یا لایه دیگری را بررسی کنید. نام دستگاه نمونه را برای سرور خودتان کپی نکنید.

اگر خطا برای ریشه سیستم است، به‌جای مسیر نمونه از این دستور استفاده کنید:

در محیط کانتینر، خروجی داخل کانتینر ممکن است با میزبان فرق کند. یک volume، تصویر کانتینر یا سیاست اجرا می‌تواند عمداً فقط‌خواندنی باشد؛ تغییر فایل‌سیستم میزبان بدون شناخت این مرز، راه مناسبی نیست.

اگر پشتیبان، فایل نصبی، snapshot یا یک volume فقط برای خواندن متصل شده، ro ممکن است همان حالت مورد انتظار باشد. در این حالت فایل جدید را در مسیر نوشتنی مجاز ذخیره کنید یا از مدیر محیط درباره روش دسترسی مناسب بپرسید؛ لازم نیست آن منبع را نوشتنی کنید.

اگر همان مسیر قبلاً نوشتنی بوده و ناگهان این خطا ظاهر شده، گزارش‌های هسته و زمان تغییر مهم‌اند. با دسترسی مجاز، این فرمان فقط برای خواندن پیام‌های هسته است:

اگر زمان شروع قدیمی‌تر است بازه را متناسب انتخاب کنید. دنبال پیام‌هایی درباره I/O error، قطع دستگاه، خطای ext4 یا XFS و فقط‌خواندنی‌شدن فایل‌سیستم بگردید. متن، زمان و نام دستگاه را با خروجی findmnt مقایسه کنید. اگر گزارش هسته در این سرور از این مسیر در دسترس نیست، مدیر ممکن است از گزارش دیگری استفاده کند؛ نبود خروجی به‌تنهایی سلامت دیسک را ثابت نمی‌کند.

گزارش‌ها ممکن است نام فایل و اطلاعات داخلی داشته باشند؛ پیش از ارسال عمومی آن‌ها را پاک‌سازی کنید. در سرور مجازی، خطای ذخیره‌سازی می‌تواند در میزبان یا شبکه ذخیره‌سازی رخ دهد و داخل مهمان علت کاملش دیده نشود. زمان و شناسه VM را برای ارائه‌دهنده نگه دارید.

ابتدا از صاحب سرویس بپرسید چرا این اتصال ro است. برای مثال ممکن است فایل پشتیبان برای جلوگیری از تغییر عمدی به این شکل متصل شده باشد. بهترین راه می‌تواند نوشتن در پوشه دیگری باشد که برای همین کار مجاز است.

اگر مدیر مجاز تأیید کرده یک دیسک داده محلی باید نوشتنی باشد، منبع سالم است و هیچ خطای فایل‌سیستم یا I/O مربوطی وجود ندارد، می‌تواند طبق روش همان سیستم اتصال را اصلاح کند. برای نمونه فرضی /data که در خروجی findmnt به‌عنوان مقصد تأیید شده، دستور زیر درخواست اتصال مجدد به حالت خواندن و نوشتن می‌دهد:

/data را فقط پس از شناسایی مقصد واقعی جایگزین کنید؛ اگر مسیر نمونه به سرور شما مربوط نیست آن را اجرا نکنید. قبل از تغییر، از تنظیم موجود نسخه داشته باشید و به وابستگی سرویس‌ها و روش بازگشت توجه کنید. این دستور معمولاً در صورت موفقیت خروجی ندارد. بلافاصله findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS را با همان مقصد واقعی تکرار کنید؛ دیدن rw یعنی حالت اتصال تغییر کرده است، نه اینکه سلامت کامل دیسک اثبات شده باشد. اگر دستور خطا داد یا مسیر دوباره ro شد، تکرارش نکنید و گزارش هسته را بخوانید. برای ماندگاری پس از بوت، تنظیم منبع مربوط باید جداگانه و با شناخت بررسی شود.

این نمونه برای یک دیسک داده محلی سالم است و نسخه عمومی برای /، NFS، snapshot یا volume کانتینر نیست. اگر سیستم پس از خطای ذخیره‌سازی خودش فقط‌خواندنی شده، دستور بالا راه‌حل تشخیص یا تعمیر نیست.

۱. عملیات نوشتن و کارهای سنگین غیرضروری روی همان مسیر را طبق برنامه توقف سرویس متوقف کنید. از تکرار نصب، استخراج و عملیات تعمیر خودکار پشت سر هم خودداری کنید. ۲. نام دقیق منبع، نوع فایل‌سیستم، زمان خطا و آخرین بکاپ را ثبت کنید. lsblk -f می‌تواند فهرست دستگاه‌ها و فایل‌سیستم‌های قابل مشاهده را نشان دهد، اما نام دستگاه ممکن است پس از بوت تغییر کند؛ UUID و معماری LVM یا RAID را نیز با مدیر سرور تطبیق دهید. ۳. اگر VPS است، از ارائه‌دهنده بخواهید وضعیت ذخیره‌سازی میزبان و خطاهای همان زمان را بررسی کند. اگر دیسک یا اتصال در حال خرابی است، قبل از تعمیر فایل‌سیستم برنامه نسخه‌برداری یا بازیابی را مشخص کنید. ۴. برای تعمیر، معمولاً لازم است فایل‌سیستم موردنظر در حال استفاده و متصل نباشد. ریشه سیستم در سرور روشن قابل جداکردن عادی نیست؛ از محیط بازیابی مستقل یا رسانه نجات ارائه‌دهنده استفاده کنید. دستور تعمیر را روی دستگاه نمونه یا روی مسیر حدسی اجرا نکنید.

اگر نوع فایل‌سیستم ext4 است، ابزار خانواده e2fsck برای بررسی و تعمیر آن استفاده می‌شود؛ اگر xfs است، ابزار مناسب و روش بازیابی آن متفاوت است. برای XFS، اجرای fsck.xfs معمولاً جای بررسی واقعی با ابزار مخصوص را نمی‌گیرد. در هر دو مورد، دستگاه درست، متصل‌نبودن، سلامت ذخیره‌سازی و نسخه پشتیبان باید پیش از اقدام تأیید شود.

برای نمونه، در یک محیط بازیابی که مدیر مطمئن شده دستگاه فرضی /dev/vdb1 همان فایل‌سیستم XFS موردنظر است و متصل نیست، بررسی بدون اعمال تعمیر ممکن است با xfs_repair -n انجام شود. اما نام دستگاه، نصب ابزار و شرایط لاگ باید برای سرور واقعی تعیین شوند. گزینه -L می‌تواند به از دست رفتن داده منجر شود و راه‌حل عمومی این خطا نیست. اگر علت، دستگاه یا وضعیت لاگ روشن نیست، از مسئول باتجربه بازیابی کمک بگیرید.

اگر تعمیر لازم باشد، گزارش ابزار و پیشنهاد آن را با نسخه پشتیبان و دستورالعمل نسخه سیستم‌عامل تطبیق دهید. ابزار تعمیر می‌تواند تغییراتی در ساختار فایل‌ها بدهد؛ به همین دلیل این مقاله دستور تغییر‌دهنده‌ای برای یک دستگاه نامشخص ارائه نمی‌کند. روی سیستم اصلی در حال اجرا، دستورهای تعمیر را برای «امتحان» اجرا نکنید.

اگر findmnt داخل کانتینر مسیر را فقط‌خواندنی نشان می‌دهد ولی میزبان در وضعیت سالم است، تنظیم volume یا فایل‌سیستم کانتینر را با مدیر برنامه بررسی کنید. بعضی برنامه‌ها عمداً فایل‌سیستم ریشه فقط‌خواندنی دارند و فقط یک پوشه داده مشخص برای نوشتن در اختیارشان قرار می‌گیرد. فایل خروجی را به مسیر مجاز منتقل کنید یا تنظیم volume را طبق طراحی و با هماهنگی مدیر اصلاح کنید؛ بازکردن نوشتن روی کل کانتینر ممکن است محدودیت امنیتی عمدی را از بین ببرد.

بعد از رفع علت و اتصال صحیح، دوباره findmnt را برای همان مسیر اجرا کنید و ببینید حالت با کاربرد موردنظر سازگار است. در یک پوشه آزمایشی مجاز و خالی، مدیر می‌تواند یک فایل متنی کوچک بسازد، محتوای آن را بخواند و سپس همان فایل آزمایشی را حذف کند؛ این کار را روی فایل واقعی مشتری انجام ندهید. پاسخ موفق یک فایل کوچک به‌تنهایی سلامت کامل دیسک را تضمین نمی‌کند.

سپس برنامه، پایگاه داده و سایت را طبق روش عملیاتی خودتان آزمایش کنید و گزارش خطاهای جدید را در بازه بعدی ببینید. اگر فایل‌سیستم دوباره فقط‌خواندنی شد، به‌جای remount مکرر، علت ذخیره‌سازی را بررسی کنید. نتیجه تعمیر یا بازیابی و زمان بازگشت سرویس را ثبت کنید.

برای شناخت امکانات و دسترسی کنسول سرویس، صفحه سرور مجازی ایران نت‌آرام را ببینید. پیش از انتخاب یا ارتقا، علت واقعی خطای ذخیره‌سازی و وضعیت داده فعلی را مشخص کنید.