رفع EXT4-fs Error و Emergency Mode در Linux با fsck

اگر سرور لینوکسی هنگام بوت به‌جای بالا آمدن عادی وارد Emergency Mode شده و در کنسول پیام‌هایی مثل EXT4-fs error، Aborting journal، Remounting filesystem read-only یا درخواست اجرای دستی fsck می‌بینید، احتمال زیادی وجود دارد که فایل‌سیستم ext4 دچار ناسازگاری متادیتا، خرابی Journal یا خطای لایه Storage شده باشد.

EXT4-fs Error چیست و چرا سرور وارد Emergency Mode می‌شود؟

ext4 یکی از فایل‌سیستم‌های رایج در Linux، Ubuntu و Debian است. وظیفه فایل‌سیستم این است که ساختار فایل‌ها، پوشه‌ها، مالکیت، زمان‌ها، فضای آزاد و اطلاعات مربوط به بلوک‌های دیسک را مدیریت کند.

ext4 برای کاهش ریسک خرابی پس از خاموشی ناگهانی از Journal استفاده می‌کند. Journal تغییرات مهم متادیتا را ثبت می‌کند تا بعد از Crash امکان بازیابی وضعیت سازگار وجود داشته باشد.

اگر کرنل هنگام کار با ext4 ناسازگاری جدی پیدا کند، بسته به تنظیمات فایل‌سیستم ممکن است آن را Read-only کند. یکی از سیاست‌های متداول ext4، گزینه زیر است:

errors=remount-ro

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

اگر خطا مربوط به فایل‌سیستم روت، یک Mount ضروری در /etc/fstab یا پارتیشن موردنیاز برای ادامه Boot باشد، systemd ممکن است سیستم را وارد Emergency Mode کند.

پیام‌های رایج هنگام خرابی ext4

بسته به علت خطا ممکن است در صفحه کنسول یا لاگ‌ها پیام‌هایی شبیه این موارد مشاهده کنید:

EXT4-fs error (device vda2)
EXT4-fs error: ext4_find_entry
EXT4-fs error: ext4_journal_check_start
EXT4-fs warning
Aborting journal on device
Remounting filesystem read-only
Buffer I/O error on dev vda2
I/O error, dev vda
Dependency failed for Local File Systems
You are in emergency mode
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

همه این پیام‌ها الزاماً یک علت ندارند. برای مثال:

• خرابی ساختار ext4 می‌تواند باعث اجرای fsck شود.
• خرابی Journal می‌تواند فایل‌سیستم را Read-only کند.
• خاموش‌شدن ناگهانی هنگام نوشتن داده می‌تواند ناسازگاری ایجاد کند.
• مشکل SSD، HDD، NVMe یا Storage میزبان VPS می‌تواند با خطای I/O ظاهر شود.
• اشتباه در /etc/fstab می‌تواند Emergency Mode ایجاد کند، حتی اگر خود ext4 سالم باشد.

قانون اول: قبل از اجرای fsck نام Device را حدس نزنید

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

/dev/sda2
/dev/vda1
/dev/vda2
/dev/nvme0n1p2
/dev/mapper/ubuntu--vg-ubuntu--lv

برای مشاهده ساختار دیسک‌ها اجرا کنید:

lsblk -f

نمونه خروجی:

NAME   FSTYPE FSVER LABEL UUID                                 MOUNTPOINTS
vda
├─vda1 vfat   FAT32       XXXX-XXXX                            /boot/efi
└─vda2 ext4   1.0         aaaa-bbbb-cccc-dddd                  /

در این مثال، فایل‌سیستم روت روی /dev/vda2 قرار دارد؛ اما روی سرور شما ممکن است Device کاملاً متفاوت باشد.

مرحله اول: لاگ خطا را بخوانید

اگر هنوز در Emergency Shell به دستورات دسترسی دارید، ابتدا دلیل ورود به Emergency Mode را پیدا کنید.

journalctl -xb -p err..alert

این دستور خطاهای مهم Boot فعلی را نمایش می‌دهد.

برای مشاهده پیام‌های کرنل:

dmesg -T | tail -n 150

برای فیلتر کردن خطاهای مرتبط با ext4 و دیسک:

dmesg -T | grep -Ei 'ext4|i/o|buffer|error|journal|nvme|scsi'

اگر عباراتی مانند I/O error یا Buffer I/O error مشاهده می‌کنید، فقط تعمیر فایل‌سیستم کافی نیست؛ احتمال مشکل Storage نیز باید بررسی شود.

مرحله دوم: ببینید Root File System چگونه Mount شده است

دستور زیر وضعیت روت را نشان می‌دهد:

findmnt /

اگر در OPTIONS عبارت ro مشاهده شد، روت فعلاً فقط‌خواندنی است.

نمونه:

TARGET SOURCE    FSTYPE OPTIONS
/      /dev/vda2 ext4   ro,relatime,errors=remount-ro

این وضعیت ممکن است نتیجه خطایی باشد که ext4 هنگام کار تشخیص داده است.

چرا نباید e2fsck را روی فایل‌سیستم Mount‌شده اجرا کنیم؟

ابزار e2fsck برای بررسی و تعمیر فایل‌سیستم‌های ext2، ext3 و ext4 استفاده می‌شود. اجرای تعمیر روی فایل‌سیستمی که هم‌زمان توسط سیستم‌عامل در حال تغییر است می‌تواند باعث نتایج نادرست یا آسیب بیشتر شود.

اگر دستور زیر نشان می‌دهد پارتیشن شما روی / Mount شده است:

findmnt /dev/vda2

نباید از داخل همان سیستم‌عامل در حال اجرا مستقیماً تعمیر کامل انجام دهید.

روش صحیح برای پارتیشن روت: Recovery Mode یا Rescue Mode

اگر فایل‌سیستم خراب همان پارتیشن روت است، بهترین روش این است که سیستم از محیط دیگری Boot شود تا فایل‌سیستم اصلی در حال استفاده نباشد.

در VPS معمولاً یکی از این امکانات وجود دارد:

• Rescue Mode
• Recovery Console
• ISO یا Live Linux
• Serial Console یا VNC Console

بعد از ورود به Rescue Mode دوباره دیسک‌ها را بررسی کنید:

lsblk -f

سپس بررسی کنید پارتیشن موردنظر Mount نشده باشد:

findmnt /dev/vda2

اگر خروجی خالی بود، یعنی احتمالاً Mount نیست.

در صورتی که Rescue Mode آن را به‌صورت خودکار Mount کرده باشد، ابتدا Mount Point را پیدا کنید و سپس Unmount کنید:

sudo umount /dev/vda2

قبل از تعمیر Backup یا Snapshot بگیرید

اگر اطلاعات سرور مهم است و پنل سرویس‌دهنده امکان Snapshot دارد، بهتر است قبل از تعمیر یک Snapshot تهیه کنید. fsck ابزاری برای اصلاح ساختار فایل‌سیستم است و ممکن است در یک فایل‌سیستم شدیداً خراب، بخش‌هایی از متادیتا را اصلاح یا فایل‌های آسیب‌دیده را به lost+found منتقل کند.

اگر Storage در حال خراب‌شدن باشد، حتی عملیات خواندن و نوشتن بیشتر نیز می‌تواند وضعیت را بدتر کند. در چنین شرایطی اولویت باید حفظ داده‌ها باشد.

مرحله اصلی: اجرای e2fsck روی ext4

بعد از اینکه مطمئن شدید Device صحیح را پیدا کرده‌اید و فایل‌سیستم Mount نیست، می‌توانید بررسی کامل را اجرا کنید.

sudo e2fsck -f /dev/vda2

در این دستور:

• e2fsck ابزار بررسی فایل‌سیستم‌های خانواده ext است.
• -f بررسی را حتی در صورتی که فایل‌سیستم ظاهراً Clean باشد مجبور به اجرا می‌کند.
• /dev/vda2 فقط نمونه Device است و باید با Device واقعی جایگزین شود.

ممکن است ابزار هنگام پیدا کردن خطا سؤال‌هایی مثل زیر نمایش دهد:

Inode bitmap differences: Fix<y>?
Free blocks count wrong. Fix<y>?
Free inodes count wrong. Fix<y>?

اگر Backup دارید و مطمئن هستید Device صحیح است، می‌توانید اصلاحات لازم را تأیید کنید.

آیا از e2fsck -y استفاده کنیم؟

دستور زیر به‌صورت خودکار به همه درخواست‌های اصلاح پاسخ Yes می‌دهد:

sudo e2fsck -f -y /dev/vda2

برای یک مبتدی بهتر است این گزینه انتخاب اول نباشد، چون تمام اصلاحات بدون بررسی تأیید می‌شوند. استفاده از -y زمانی منطقی‌تر است که Snapshot یا Backup معتبر دارید و می‌دانید چه Deviceای را تعمیر می‌کنید.

خروجی موفق e2fsck چه شکلی است؟

اگر تعمیر انجام شود، ممکن است در پایان خروجی شبیه این ببینید:

/dev/vda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vda2: 182341/2621440 files, 1765432/10485760 blocks

عبارت FILE SYSTEM WAS MODIFIED یعنی e2fsck تغییراتی برای اصلاح فایل‌سیستم انجام داده است.

اگر ابزار اعلام کرد فایل‌سیستم Clean است و خطا همچنان باقی مانده، باید علت‌های دیگری مانند Storage، /etc/fstab یا Device اشتباه بررسی شوند.

آیا fsck را دوباره اجرا کنیم؟

بعد از تعمیر یک فایل‌سیستم خراب، می‌توانید یک بار دیگر بررسی را اجرا کنید:

sudo e2fsck -f /dev/vda2

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

اگر خطای Bad Superblock دریافت کردیم چه کنیم؟

Superblock اطلاعات اصلی ساختار فایل‌سیستم را نگه می‌دارد. ext4 معمولاً نسخه‌های پشتیبان از Superblock را در نقاط مشخصی نگهداری می‌کند.

اگر e2fsck پیامی درباره Superblock خراب نمایش دهد، ابتدا با دقت Device را تأیید کنید. برای مشاهده محل احتمالی Backup Superblockها می‌توان از حالت بدون ساخت فایل‌سیستم mke2fs استفاده کرد:

sudo mke2fs -n /dev/vda2

اگر Backup Superblock معتبر مثلاً شماره 32768 باشد، تعمیر می‌تواند به‌شکل زیر انجام شود:

sudo e2fsck -b 32768 /dev/vda2

شماره 32768 فقط مثال است و نباید بدون بررسی روی سرور واقعی استفاده شود.

اگر ext4 سالم است اما سرور هنوز وارد Emergency Mode می‌شود

گاهی مشکل اصلی /etc/fstab است. این فایل مشخص می‌کند هنگام Boot چه فایل‌سیستم‌هایی و در چه مسیرهایی Mount شوند.

اگر UUID یک دیسک تغییر کرده باشد یا Device حذف شده باشد، systemd ممکن است برای Mount کردن آن منتظر بماند و در نهایت وارد Emergency Mode شود.

برای مشاهده فایل:

cat /etc/fstab

UUIDهای واقعی را ببینید:

blkid

برای بررسی ساختار fstab:

findmnt --verify

اگر لازم است فایل را تغییر دهید، ابتدا نسخه پشتیبان بسازید:

cp /etc/fstab /etc/fstab.backup

بعد از اصلاح، در شرایطی که سیستم پایدار است می‌توانید Mountهای تعریف‌شده را بررسی کنید:

mount -av

اگر در لاگ I/O Error وجود دارد، فقط fsck کافی نیست

این بخش بسیار مهم است. فرض کنید e2fsck فایل‌سیستم را تعمیر می‌کند اما چند ساعت یا چند روز بعد دوباره خطا برمی‌گردد. در این شرایط باید احتمال مشکل Storage را جدی گرفت.

نمونه پیام‌ها:

I/O error, dev sda
Buffer I/O error on dev vda2
blk_update_request: I/O error
critical medium error
EXT4-fs error

در سرور فیزیکی می‌توانید سلامت دیسک را با SMART بررسی کنید.

روی Ubuntu/Debian:

sudo apt update
sudo apt install smartmontools

برای SATA/SAS، بسته به Device:

sudo smartctl -a /dev/sda

روی VPS معمولاً SMART دیسک فیزیکی از داخل ماشین مجازی در دسترس نیست. اگر خطاهای I/O تکرار می‌شوند، باید از ارائه‌دهنده سرویس بخواهید Storage میزبان را بررسی کند.

خاموشی ناگهانی و Crash چه تأثیری دارند؟

ext4 دارای Journal است و معمولاً بعد از خاموشی ناگهانی می‌تواند با Replay کردن Journal به وضعیت سازگار برگردد. با این حال قطع برق، Reset سخت، Kernel Crash یا مشکل Storage در حین نوشتن داده می‌تواند شرایطی ایجاد کند که بررسی کامل فایل‌سیستم لازم شود.

اگر این اتفاق مرتب تکرار می‌شود، فقط به تعمیر ext4 بسنده نکنید. علت Crash، خاموشی یا Reset نیز باید پیدا شود.

سناریوی نمونه روی VPS اوبونتو

فرض کنید یک VPS پس از ریبوت وارد Emergency Mode شده و کنسول پیام زیر را نشان می‌دهد:

EXT4-fs error (device vda2)
Remounting filesystem read-only
You are in emergency mode

روند منطقی عیب‌یابی:

1. از پنل ارائه‌دهنده وارد Console شوید.
2. با journalctl -xb خطای واقعی را بررسی کنید.
3. با lsblk -f مشخص کنید ext4 روی کدام Device است.
4. اگر روت آسیب دیده، سرور را وارد Rescue Mode کنید.
5. در صورت امکان Snapshot بگیرید.
6. بررسی کنید پارتیشن Mount نباشد.
7. e2fsck -f را روی Device صحیح اجرا کنید.
8. بعد از اتمام تعمیر یک بار دیگر e2fsck را اجرا کنید.
9. Rescue Mode را غیرفعال کرده و سیستم را Boot کنید.
10. پس از Boot لاگ کرنل را برای خطای I/O بررسی کنید.

بعد از تعمیر و Boot موفق چه چیزهایی را بررسی کنیم؟

پس از بالا آمدن سیستم، اول وضعیت روت را ببینید:

findmnt /

در OPTIONS باید در حالت معمول rw مشاهده شود.

بعد لاگ کرنل را بررسی کنید:

dmesg -T | grep -Ei 'ext4|i/o|buffer|error|journal'

برای دیدن خطاهای Boot فعلی:

journalctl -b -p err..alert

اگر می‌خواهید Boot قبلی را که منجر به Emergency Mode شده بررسی کنید:

journalctl -b -1 -k

البته این دستور زمانی اطلاعات Boot قبل را نشان می‌دهد که Journal سیستم به‌صورت Persistent نگهداری شده باشد.

تست نوشتن روی فایل‌سیستم

بعد از تعمیر می‌توانید یک فایل موقت ایجاد و حذف کنید:

sudo touch /tmp/ext4-write-test
ls -l /tmp/ext4-write-test
sudo rm /tmp/ext4-write-test

اگر عملیات بدون خطا انجام شد و findmnt نیز rw نشان می‌دهد، فایل‌سیستم قابل‌نوشتن است.

چه کارهایی را نباید انجام دهیم؟

• Device را از روی حدس انتخاب نکنید.
• روی فایل‌سیستم Mount‌شده تعمیر کامل e2fsck اجرا نکنید.
• به‌محض دیدن Emergency Mode، بدون خواندن لاگ‌ها fsck نزنید.
• خطاهای I/O را نادیده نگیرید.
• از e2fsck -y بدون Backup و بررسی Device استفاده نکنید.
• دستور mke2fs را بدون آگاهی از کاربرد آن اجرا نکنید.
• بعد از تعمیر موفق، بررسی Storage را در صورت تکرار خطا فراموش نکنید.

تفاوت Emergency Mode و Rescue Mode چیست؟

Emergency Mode حالتی است که systemd هنگام وجود مشکل جدی در Boot، Mountها یا سرویس‌های حیاتی وارد آن می‌شود. در این حالت حداقل محیط ممکن برای عیب‌یابی ارائه می‌شود.

Rescue Mode در بسیاری از پنل‌های VPS یک سیستم‌عامل یا محیط بوت جداگانه است که به شما اجازه می‌دهد دیسک اصلی سرور را بدون Boot کردن سیستم‌عامل خراب بررسی کنید. برای تعمیر فایل‌سیستم روت، Rescue Mode معمولاً گزینه امن‌تری است.

سؤالات متداول

خطای EXT4-fs error دقیقاً به چه معناست؟

این پیام یعنی در زمان کار با فایل‌سیستم ext4 خطایی تشخیص داده شده است. علت می‌تواند ناسازگاری متادیتا، مشکل Journal یا خطای لایه دیسک و Storage باشد. متن کامل لاگ مشخص می‌کند کدام احتمال جدی‌تر است.

چرا بعد از EXT4-fs error فایل‌سیستم Read-only می‌شود؟

ext4 می‌تواند طوری تنظیم شده باشد که هنگام مشاهده خطا، فایل‌سیستم را با حالت Read-only دوباره Mount کند. این رفتار برای جلوگیری از نوشتن بیشتر روی فایل‌سیستم آسیب‌دیده استفاده می‌شود.

آیا در Emergency Mode می‌توان مستقیم fsck اجرا کرد؟

فقط اگر فایل‌سیستم موردنظر Mount نباشد یا شرایط تعمیر آن را دقیقاً بررسی کرده باشید. برای پارتیشن روت، روش امن‌تر استفاده از Recovery یا Rescue Mode و اجرای e2fsck روی Device غیر Mount است.

برای ext4 از fsck استفاده کنیم یا e2fsck؟

e2fsck ابزار مخصوص خانواده ext2، ext3 و ext4 است. فرمان‌هایی مانند fsck.ext4 نیز در عمل به ابزار خانواده e2fsprogs مرتبط هستند. در این مقاله از e2fsck استفاده شده تا نوع ابزار مشخص باشد.

اگر e2fsck خطاها را رفع کرد ولی مشکل دوباره برگشت چه کنیم؟

تکرار خطا می‌تواند نشانه مشکل Storage، دیسک، کنترلر، خاموشی‌های ناگهانی یا زیرساخت میزبان VPS باشد. در این وضعیت لاگ‌های I/O را بررسی کنید و در VPS موضوع را با ارائه‌دهنده سرویس در میان بگذارید.

آیا e2fsck باعث حذف فایل‌ها می‌شود؟

هدف e2fsck ترمیم ساختار فایل‌سیستم است، اما در فایل‌سیستم شدیداً خراب ممکن است فایل‌ها یا قطعاتی که ارتباط ساختاری سالم ندارند به lost+found منتقل شوند یا بخشی از داده قابل بازیابی نباشد. به همین دلیل Backup یا Snapshot قبل از تعمیر اهمیت دارد.

آیا Emergency Mode همیشه به‌دلیل خراب شدن ext4 است؟

خیر. اشتباه در /etc/fstab، Mount نشدن یک دیسک، UUID اشتباه، مشکلات LVM و سرویس‌های حیاتی نیز می‌توانند باعث Emergency Mode شوند. وجود پیام‌های EXT4-fs error مشخص می‌کند بررسی فایل‌سیستم باید در اولویت باشد، اما نباید بقیه علت‌ها نادیده گرفته شوند.