Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.
Dependency failed for Local File Systems (Failed to mount /mountpoint) Linux / DevOps

Dependency failed for Local File Systems — Ошибка монтирования дисков

Обновлено: 18.08.2026  ·  Официальная база знаний

Архитектура ошибки и симптомы сбоя

Каскадный сбой загрузки «Dependency failed for Local File Systems» (сопровождающийся «Failed to mount /mountpoint» и «Dependency failed for local-fs.target») возникает в подсистеме systemd Local File Systems Management. Ошибка означает, что один из базовых локальных разделов (/home, /var, /opt или /boot) не смог смонтироваться из-за повреждения структуры метаданных файловой системы (требуется ручной запуск fsck), некорректных опций монтирования в /etc/fstab или отсутствия каталога точки монтирования.

Диагностическая таблица параметров сбоя

ПараметрЗначениеИнженерный смысл сбоя
local-fs.targetSystem Mount TargetКритический системный таргет, объединяющий монтирование всех локальных ФС.
fsck (File System Check)Integrity VerificationСлужба проверки целостности superblock, inode и журналов файловой системы.
Dependency ChainCascading Boot FailureОтказ одной ФС блокирует переход к sysinit.target и multi-user.target.

Пошаговое дерево решений и сценарии траблшутинга

Сценарий 1: Проверка точной ошибки монтирования в журнале загрузки

# Поиск точки монтирования, вызвавшей сбой:
journalctl -xb | grep -i -E "(failed to mount|dependency failed|fsck)"

# Проверка статуса конкретного mount-юнита (например, var.mount):
systemctl status var.mount

Сценарий 2: Ручное восстановление поврежденной файловой системы (fsck)

Если ядро обнаружило повреждение метаданных и требует ручного запуска fsck:

# 1. Убедитесь, что проверяемый раздел РАЗМОНТИРОВАН:
umount /dev/sdb1

# 2. Запуск проверки и автоматического исправления поврежденных блоков:
# Для ext4:
sudo fsck.ext4 -y -v -f /dev/sdb1

# Для XFS (используйте xfs_repair):
sudo xfs_repair -v /dev/sdb1

Сценарий 3: Создание отсутствующего каталога точки монтирования

Если раздел не может смонтироваться из-за отсутствия директории назначения:

# Создание точки монтирования с корректными правами:
sudo mkdir -p /mnt/data
sudo chmod 755 /mnt/data

# Тестовое монтирование всех разделов из fstab без перезагрузки:
sudo mount -a

Сценарий 4: Временное отключение сбойной строки в /etc/fstab

Если диск физически неисправен, закомментируйте его строку в /etc/fstab (символ # в начале строки), выполните systemctl daemon-reload и перезагрузите сервер.

Файловая система XFS или ext4 повреждена и не дает загрузить сервер?
ITSTM выполнит профессиональное восстановление поврежденных суперблоков ФС, реконструкцию LVM-метаданных и сохранение ценных данных.
Практический опыт инженера: Для файловых систем XFS всегда выставляйте последнюю цифру в /etc/fstab в '0' (UUID=... /data xfs defaults 0 0), так как XFS выполняет самовосстановление журнала при монтировании ядра, а сторонний вызов fsck при старте только создает лишние риски.

Частые вопросы (FAQ)

Почему xfs_repair не работает на смонтированной файловой системе?

Файловые системы XFS принципиально запрещено восстанавливать в смонтированном состоянии во избежание катастрофического разрушения данных. Раздел обязательно должен быть полностью размонтирован перед запуском xfs_repair.

Что означает последняя цифра '0 2' в строке /etc/fstab?

Последнее число (fs_passno) определяет порядок проверки диска утилитой fsck при загрузке: 1 — корневой раздел '/', 2 — остальные локальные разделы, 0 — проверка диска отключена (рекомендовано для XFS, Btrfs и сетевых шар).

Что делать, если xfs_repair выдает ошибку 'Structure needs cleaning' и жалуется на dirty log?

Если журнал XFS поврежден, можно принудительно очистить его командой xfs_repair -L /dev/sdX (применяйте только как крайнюю меру, возможна потеря последних незаписанных транзакций).

Как systemd преобразует пути монтирования в имена mount-юнитов?

systemd заменяет слэши на дефисы: каталог /var/log преобразуется в юнит var-log.mount, а корень / — в -.mount.