رفع Dependency Failed و خطاهای UUID در fstab لینوکس

اگر هنگام بوت لینوکس پیام‌هایی مثل Dependency failed for /data، Dependency failed for Local File Systems، Timed out waiting for device /dev/disk/by-uuid/... یا special device UUID=... does not exist می‌بینید، یکی از اولین فایل‌هایی که باید بررسی شود /etc/fstab است. این فایل مشخص می‌کند چه دیسک‌ها و پارتیشن‌هایی هنگام بوت، در چه مسیری و با چه تنظیماتی Mount شوند.

خطای Dependency Failed در زمان Boot یعنی چه؟

در توزیع‌هایی که از systemd استفاده می‌کنند، ورودی‌های /etc/fstab هنگام بوت به Mount Unitهای systemd تبدیل می‌شوند. اگر یک Mount مهم به Deviceای وابسته باشد که پیدا نشود، UUID اشتباه داشته باشد یا Mount آن شکست بخورد، سرویس‌ها و Targetهایی که به آن وابسته‌اند نیز ممکن است Failed شوند.

برای مثال ممکن است کنسول سرور چنین پیام‌هایی نمایش دهد:

[ TIME ] Timed out waiting for device /dev/disk/by-uuid/1111-2222.
[DEPEND] Dependency failed for /data.
[DEPEND] Dependency failed for Local File Systems.

در این مثال مشکل اصلی لزوماً خود local-fs.target نیست. ابتدا باید فهمید چرا Device دارای UUID مورد انتظار پیدا نشده است.

فایل /etc/fstab چیست؟

/etc/fstab یک فایل متنی برای تعریف فایل‌سیستم‌هایی است که سیستم باید آن‌ها را Mount کند. هر خط معمولاً شش فیلد دارد.

نمونه:

UUID=7c9b8d4a-1111-2222-3333-abcdef123456 /data ext4 defaults 0 2

این خط به زبان ساده می‌گوید:

• پارتیشن با UUID مشخص‌شده را پیدا کن.
• آن را روی مسیر /data Mount کن.
• نوع فایل‌سیستم ext4 است.
• از گزینه‌های Mount پیش‌فرض استفاده کن.
• فیلد پنجم مربوط به dump است.
• فیلد ششم ترتیب بررسی فایل‌سیستم در فرایند fsck را مشخص می‌کند.

چرا در fstab از UUID استفاده می‌شود؟

نام‌هایی مثل /dev/sda1، /dev/sdb1 یا /dev/vdb1 همیشه بهترین شناسه برای یک فایل‌سیستم نیستند، چون ترتیب شناسایی Deviceها ممکن است در بعضی شرایط تغییر کند.

UUID شناسه‌ای است که به خود فایل‌سیستم نسبت داده می‌شود. به همین دلیل ورودی زیر معمولاً پایدارتر از استفاده مستقیم از نام Device است:

UUID=7c9b8d4a-1111-2222-3333-abcdef123456 /data ext4 defaults 0 2

در مقابل:

/dev/sdb1 /data ext4 defaults 0 2

اگر نام Device تغییر کند، خط دوم ممکن است Device دیگری را هدف بگیرد یا اصلاً کار نکند.

UUID چرا اشتباه یا تغییر می‌کند؟

چند سناریوی رایج باعث می‌شود UUID موجود در fstab دیگر با فایل‌سیستم واقعی مطابقت نداشته باشد:

• پارتیشن دوباره فرمت شده است.
• فایل‌سیستم جدیدی با mkfs ساخته شده است.
• دیسک قدیمی حذف و دیسک جدید جایگزین شده است.
• Snapshot یا Clone به‌شکل دیگری Restore شده است.
• ساختار LVM یا پارتیشن‌بندی تغییر کرده است.
• یک Volume ابری Detach یا حذف شده است.
• UUID داخل fstab هنگام ویرایش دستی اشتباه وارد شده است.
• ورودی fstab مربوط به دیسکی است که دیگر به سرور متصل نیست.

مرحله اول: بفهمید کدام Mount شکست خورده است

اگر داخل Emergency Mode یا Shell هستید، ابتدا Unitهای Failed را مشاهده کنید:

systemctl --failed

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

journalctl -xb -p warning..alert

برای تمرکز روی پیام‌های مربوط به Mount و Device نیز می‌توانید اجرا کنید:

journalctl -xb | grep -Ei 'mount|uuid|dependency|device|fstab|local-fs'

به UUID و Mount Pointی که در خطا دیده می‌شود دقت کنید.

مرحله دوم: محتویات fstab را بررسی کنید

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

cat /etc/fstab

یا برای نمایش همراه با شماره خط:

nl -ba /etc/fstab

نمونه:

UUID=aaaa-bbbb / ext4 defaults,errors=remount-ro 0 1
UUID=1111-2222 /data ext4 defaults 0 2
UUID=3333-4444 none swap sw 0 0

مرحله سوم: UUID واقعی دیسک‌ها را پیدا کنید

برای کاربر مبتدی، یکی از ساده‌ترین دستورها این است:

lsblk -f

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

NAME   FSTYPE FSVER LABEL UUID                                 MOUNTPOINTS
vda
├─vda1 vfat   FAT32       A1B2-C3D4                            /boot/efi
└─vda2 ext4   1.0         aaaa-bbbb-cccc-dddd                  /
vdb
└─vdb1 ext4   1.0         9999-8888-7777-6666

برای مشاهده شناسه‌ها با ابزار blkid:

sudo blkid

ممکن است ببینید:

/dev/vda2: UUID="aaaa-bbbb-cccc-dddd" TYPE="ext4"
/dev/vdb1: UUID="9999-8888-7777-6666" TYPE="ext4"

حالا UUID واقعی را با مقداری که داخل /etc/fstab نوشته شده مقایسه کنید.

مرحله چهارم: UUIDهای fstab را با Device واقعی تطبیق دهید

ابزار findmnt می‌تواند ورودی‌های fstab را بخواند و UUIDها را به Device واقعی تبدیل کند:

findmnt --fstab --evaluate

اگر UUID یک ورودی وجود داشته باشد، معمولاً Device متناظر قابل شناسایی است. اگر Device مورد انتظار پیدا نمی‌شود، باید مشخص کنید آیا UUID اشتباه است یا خود دیسک دیگر وجود ندارد.

قبل از ویرایش fstab بکاپ بگیرید

قبل از هر تغییر:

sudo cp -a /etc/fstab /etc/fstab.backup

برای اطمینان:

ls -l /etc/fstab*

اگر در Emergency Mode نمی‌توانید fstab را ذخیره کنید

ممکن است فایل‌سیستم روت در Emergency Mode به‌صورت Read-only Mount شده باشد. وضعیت را بررسی کنید:

findmnt /

اگر در OPTIONS عبارت ro دیده می‌شود و مطمئن هستید خرابی فایل‌سیستم علت Read-only شدن نیست، ممکن است بتوانید روت را موقتاً قابل‌نوشتن کنید:

sudo mount -o remount,rw /

اگر هم‌زمان خطاهای EXT4-fs error یا I/O error وجود دارد، ابتدا مشکل فایل‌سیستم یا Storage را بررسی کنید و Remount اجباری را راه‌حل اصلی در نظر نگیرید.

سناریو اول: UUID داخل fstab اشتباه است

فرض کنید fstab چنین خطی دارد:

UUID=1111-2222 /data ext4 defaults 0 2

اما blkid نشان می‌دهد UUID واقعی پارتیشن /dev/vdb1 این است:

UUID="9999-8888-7777-6666"

فایل را با ویرایشگر باز کنید:

sudo nano /etc/fstab

ورودی را به UUID واقعی تغییر دهید:

UUID=9999-8888-7777-6666 /data ext4 defaults 0 2

نوع فایل‌سیستم یعنی ext4 را نیز با خروجی lsblk -f تطبیق دهید.

سناریو دوم: دیسک از سرور حذف شده ولی هنوز در fstab وجود دارد

این حالت در VPSها و سرورهایی که Volume جداگانه دارند بسیار رایج است. مثلاً یک دیسک Data قبلاً روی /backup Mount می‌شده، اما بعداً Volume حذف شده است.

fstab هنوز چنین خطی دارد:

UUID=5555-6666 /backup ext4 defaults 0 2

اما UUID موردنظر در خروجی زیر وجود ندارد:

sudo blkid

اگر مطمئن هستید آن دیسک دیگر نباید استفاده شود، می‌توانید خط را حذف یا موقتاً Comment کنید:

# UUID=5555-6666 /backup ext4 defaults 0 2

بعد صحت فایل را تست کنید.

سناریو سوم: دیسک اختیاری است و نمی‌خواهید نبود آن Boot را متوقف کند

اگر یک دیسک واقعاً اختیاری است، مثلاً Volume آرشیو یا Backup که نبود آن نباید جلوی بالا آمدن سیستم‌عامل را بگیرد، گزینه nofail قابل استفاده است.

نمونه:

UUID=9999-8888-7777-6666 /backup ext4 defaults,nofail 0 2

با nofail، systemd این Mount را برای Boot به‌شکل اجباری Require نمی‌کند و شکست Mount الزاماً مانع رسیدن سیستم به Target مربوط نمی‌شود.

کاهش زمان انتظار برای دیسک‌های اختیاری

اگر Device اختیاری است و گاهی وجود ندارد، systemd گزینه x-systemd.device-timeout= را برای ورودی‌های fstab می‌شناسد.

مثال:

UUID=9999-8888-7777-6666 /backup ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

در این نمونه systemd برای ظاهرشدن Device مدت محدودی منتظر می‌ماند.

این گزینه نیز باید برای Mount اختیاری و با آگاهی از اثر آن استفاده شود؛ کم‌کردن Timeout برای دیسکی که واقعاً لازم است ممکن است فقط مشکل زمان‌بندی Storage را پنهان کند.

مرحله پنجم: قبل از ریبوت fstab را بررسی کنید

این مرحله را حذف نکنید. بعد از ویرایش فایل، ابتدا اجرا کنید:

sudo findmnt --verify --verbose

این فرمان ساختار و قابل‌استفاده بودن ورودی‌های fstab را بررسی می‌کند.

اگر خطایی نمایش داده شد، قبل از ریبوت آن را اصلاح کنید.

بعد از تغییر fstab، systemd را Reload کنید

systemd ورودی‌های fstab را به Mount Unit تبدیل می‌کند. پس از ویرایش fstab اجرا کنید:

sudo systemctl daemon-reload

این کار Generatorهای systemd را دوباره اجرا می‌کند تا تنظیمات جدید در نظر گرفته شوند.

مرحله ششم: بدون ریبوت Mountها را تست کنید

پس از اینکه findmnt --verify خطای مهمی نشان نداد، می‌توانید ورودی‌های fstab را تست کنید:

sudo mount -av

گزینه -a تلاش می‌کند ورودی‌های مناسب fstab را Mount کند و -v خروجی جزئی‌تر نمایش می‌دهد.

نمونه خروجی موفق:

/                        : ignored
/data                    : successfully mounted

اگر Mount با خطا مواجه شد، هنوز ریبوت نکنید. متن خطا را بررسی کنید.

چطور نتیجه را بررسی کنیم؟

برای مشاهده Mount موردنظر:

findmnt /data

یا برای یک فایل‌سیستم مشخص:

findmnt -T /data

همچنین می‌توانید فضای فایل‌سیستم‌ها را مشاهده کنید:

df -hT

پاک کردن وضعیت Failed بعد از رفع مشکل

بعد از اصلاح مشکل ممکن است بعضی Unitها هنوز در خروجی systemd به‌عنوان Failed دیده شوند. ابتدا بررسی کنید:

systemctl --failed

اگر مشکل واقعاً برطرف شده است، وضعیت Failed ثبت‌شده را می‌توان پاک کرد:

sudo systemctl reset-failed

این دستور علت خطا را تعمیر نمی‌کند؛ فقط وضعیت Failed ثبت‌شده را Reset می‌کند.

اگر UUID مربوط به پارتیشن Root اشتباه باشد چه کنیم؟

این سناریو حساس‌تر است. اگر ورودی روت در fstab اشتباه باشد، سیستم ممکن است در بوت با مشکل مواجه شود. اما اگر حتی فایل‌سیستم روت پیدا نشود، مشکل ممکن است فقط fstab نباشد و تنظیمات Bootloader یا initramfs نیز درگیر باشند.

اگر سیستم وارد Emergency Mode شده ولی روت Mount است، ابتدا Device روت را پیدا کنید:

findmnt /

سپس UUID واقعی آن را ببینید:

lsblk -f

ورودی / در fstab باید با فایل‌سیستم واقعی تطبیق داشته باشد.

اگر سیستم به‌قدری مشکل دارد که حتی Root File System بوت نمی‌شود، از Rescue Mode یا Live Linux استفاده کنید، فایل‌سیستم سرور را Mount کنید و fstab را از محیط Rescue اصلاح کنید.

ویرایش fstab از Rescue Mode

فرض کنیم پارتیشن روت واقعی /dev/vda2 است. ابتدا آن را در یک مسیر موقت Mount کنید:

sudo mkdir -p /mnt/server
sudo mount /dev/vda2 /mnt/server

سپس fstab سیستم اصلی را مشاهده کنید:

cat /mnt/server/etc/fstab

قبل از تغییر بکاپ بگیرید:

sudo cp -a /mnt/server/etc/fstab /mnt/server/etc/fstab.backup

بعد فایل را ویرایش کنید:

sudo nano /mnt/server/etc/fstab

UUID تکراری بعد از Clone دیسک

گاهی Clone کردن یک فایل‌سیستم باعث می‌شود دو Device با UUID یکسان در سیستم وجود داشته باشند. این وضعیت می‌تواند شناسایی Device را مبهم کند.

با این دستورات وضعیت را بررسی کنید:

lsblk -f
sudo blkid

اگر دو فایل‌سیستم واقعاً UUID یکسان دارند، قبل از هر تغییری مشخص کنید کدام کپی باید مورد استفاده باشد. تغییر UUID وابسته به نوع فایل‌سیستم است و نباید با یک دستور عمومی و بدون Backup انجام شود.

خطای UUID مربوط به Swap

گاهی سرور Boot می‌شود اما در لاگ خطایی درباره Swap قدیمی دیده می‌شود. ابتدا Swapهای فعلی را ببینید:

swapon --show

سپس fstab و Deviceها را مقایسه کنید:

grep -v '^[[:space:]]*#' /etc/fstab
sudo blkid

اگر Swap قدیمی حذف شده است، ورودی نامعتبر را اصلاح کنید. اگر Swap جدید ساخته‌اید، UUID جدید باید با تنظیمات واقعی سیستم مطابقت داشته باشد.

اشتباه‌های رایج هنگام رفع Dependency Failed

• حذف تصادفی ورودی پارتیشن Root از fstab؛
• جایگزین کردن UUID با یک Device حدسی مثل /dev/sdb1؛
• ویرایش fstab بدون تهیه Backup؛
• ریبوت فوری بدون اجرای findmnt --verify؛
• استفاده از nofail برای پنهان کردن خرابی یک دیسک حیاتی؛
• نادیده گرفتن خطاهای I/O و فرض اینکه همه مشکلات فقط UUID هستند؛
• ویرایش UUID بدون بررسی نوع فایل‌سیستم؛
• فراموش کردن systemctl daemon-reload بعد از تغییر fstab روی سیستم systemd؛
• فرض اینکه systemctl reset-failed خود مشکل Mount را تعمیر می‌کند.

روال امن پیشنهادی

1. با systemctl --failed و journalctl -xb Mount خراب را پیدا کنید.
2. با cat /etc/fstab ورودی مربوطه را مشخص کنید.
3. با lsblk -f و blkid UUID واقعی را پیدا کنید.
4. از /etc/fstab بکاپ بگیرید.
5. UUID، Mount Point، Filesystem Type و Options را اصلاح کنید.
6. findmnt --verify --verbose را اجرا کنید.
7. systemctl daemon-reload را اجرا کنید.
8. با mount -av Mountها را قبل از ریبوت تست کنید.
9. با findmnt نتیجه را تأیید کنید.
10. بعد از اطمینان از صحت تنظیمات سرور را ریبوت کنید.

Rollback؛ اگر بعد از تغییر وضعیت بدتر شد

اگر هنوز به Shell دسترسی دارید، بکاپ قبلی را بازگردانید:

sudo cp -a /etc/fstab.backup /etc/fstab
sudo systemctl daemon-reload
sudo findmnt --verify --verbose

اگر سیستم دیگر Boot نمی‌شود، وارد Rescue Mode شوید و فایل Backup را روی Root File System اصلی برگردانید.

مثلاً اگر روت روی /mnt/server Mount شده است:

sudo cp -a /mnt/server/etc/fstab.backup /mnt/server/etc/fstab

چه زمانی مشکل اصلاً از fstab نیست؟

اگر UUIDها صحیح‌اند ولی Device ناپدید می‌شود یا Mount مرتب شکست می‌خورد، موارد زیر را بررسی کنید:

• خطای دیسک یا Storage؛
• مشکل LVM؛
• خرابی ext4 یا XFS؛
• Volume ابری که به VM Attach نشده است؛
• مشکل RAID؛
• دیسک رمزگذاری‌شده که باز نشده است؛
• Mount شبکه‌ای که قبل از آماده‌شدن Network اجرا می‌شود.

برای خطاهای Storage و فایل‌سیستم، لاگ کرنل را ببینید:

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

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

خطای Dependency Failed for Local File Systems یعنی چه؟

این پیام معمولاً یعنی یکی از Mountهای محلی که systemd برای Boot به آن وابسته است موفق نشده است. برای پیدا کردن علت اصلی باید Unitهای Failed، لاگ Boot و ورودی‌های fstab را بررسی کنید.

چطور UUID واقعی یک پارتیشن را پیدا کنیم؟

ساده‌ترین روش استفاده از lsblk -f یا blkid است. UUID نمایش‌داده‌شده را با مقدار ثبت‌شده در /etc/fstab مقایسه کنید.

آیا می‌توان UUID اشتباه را با /dev/sdb1 جایگزین کرد؟

از نظر فنی fstab می‌تواند از Device Path استفاده کند، اما برای فایل‌سیستم‌های معمول استفاده از UUID معمولاً پایدارتر است، چون نام‌هایی مانند /dev/sdb1 ممکن است با تغییر ترتیب شناسایی Deviceها عوض شوند.

گزینه nofail در fstab چه کاری انجام می‌دهد؟

در سیستم‌های systemd، nofail باعث می‌شود Mount موردنظر برای ادامه Boot به‌صورت اجباری Required نباشد. این گزینه برای دیسک‌های واقعاً اختیاری مناسب است، نه برای پنهان کردن خرابی Storage یا Mountهای حیاتی.

بعد از ویرایش fstab باید حتماً سرور را ریبوت کنیم؟

خیر. بهتر است قبل از ریبوت با findmnt --verify --verbose فایل را بررسی کنید، systemctl daemon-reload بزنید و سپس در صورت مناسب بودن شرایط با mount -av Mountها را تست کنید.

چرا UUID بعد از فرمت پارتیشن تغییر کرده است؟

UUID متعلق به فایل‌سیستم است. وقتی فایل‌سیستم جدیدی ساخته می‌شود، معمولاً UUID جدیدی نیز ایجاد می‌شود؛ بنابراین ورودی قدیمی fstab باید با وضعیت جدید تطبیق داده شود.

اگر دیسک اختیاری دیگر وجود ندارد، خط fstab را حذف کنیم یا nofail بگذاریم؟

اگر دیسک برای همیشه حذف شده و دیگر استفاده نخواهد شد، حذف یا Comment کردن ورودی معمولاً شفاف‌تر است. اگر دیسک گاهی وجود دارد و نبود آن نباید Boot را متوقف کند، nofail می‌تواند مناسب باشد.

آیا systemctl reset-failed مشکل Dependency Failed را حل می‌کند؟

خیر. این فرمان فقط وضعیت Failed ثبت‌شده در systemd را پاک می‌کند. ابتدا باید UUID، Device، Mount یا علت اصلی خطا را اصلاح کنید.