Автомонтирование и почему сервер не загрузился после правки fstab

MAATRIX

Вы добавили в /etc/fstab строку под новый диск, перезагрузили сервер — и он не поднялся. SSH молчит, сайт лежит, а единственное, что вы видите в панели провайдера — надпись «система не отвечает». Это одна из самых частых причин недоступности сервера после, казалось бы, безобидной правки конфига, и в этой статье разберём, почему так происходит и как проверять fstab так, чтобы подобное больше не повторилось.

Что вообще делает fstab при загрузке

/etc/fstab — это таблица файловых систем: каждая строка описывает, какое устройство куда монтировать и с какими опциями. Формат строки:

<устройство> <точка монтирования> <тип ФС> <опции> <dump> <pass>

Например:

UUID=3a1f0c9e-8b2d-4e11-9c77-1a2b3c4d5e6f  /data  ext4  defaults  0  2
/dev/sdb1  /mnt/backup  ext4  defaults  0  2
storage-nas:/exports/data  /mnt/nas  nfs  defaults,_netdev  0  0

При загрузке ядро поднимает корневую файловую систему, а дальше systemd (или, в старых системах, скрипты init) генерирует из fstab юниты монтирования и пытается смонтировать все перечисленные записи — не только корень и /boot, а буквально каждую строку, включая внешний диск, который вы подключали для разовой копии полгода назад и с тех пор отключили.

Логика на первый взгляд разумная: раз администратор прописал точку монтирования в fstab, значит она должна быть доступна на боевой системе. Но именно эта строгость и превращается в ловушку для удалённого сервера.

Механизм отказа: почему одна строка кладёт всю систему

Если устройство, указанное в fstab, не найдено — диск не подключён, UUID указан с опечаткой, NFS-шара недоступна по сети, — по умолчанию systemd не пропускает эту запись молча. Вместо этого он:

1. Ждёт таймаут (обычно около 90 секунд) в надежде, что устройство появится.
2. Не дождавшись, помечает загрузку как неуспешную для этой точки монтирования.
3. Поскольку local-fs.target (или remote-fs.target для сетевых ФС) считается зависимостью для перехода в многопользовательский режим, система не продолжает обычную загрузку, а падает в emergency mode — аварийный shell, где просят ввести пароль root и разобраться руками.

Именно тут удалённый сервер превращается в кирпич. Emergency shell слушает только локальную консоль — ни SSH, ни обычные сетевые сервисы к этому моменту не поднимаются, потому что до них загрузка попросту не доходит. Если у вас нет IPMI, KVM-over-IP или консоли провайдера, единственный способ вмешаться — открыть тикет в поддержку и просить кого-то физически подключиться к серверу, объяснить, что править, и ждать. Для домашнего компьютера это неудобство на пять минут. Для боевого сервера в другой стране — простой на часы, а иногда и на сутки, пока тикет доедет до дежурного инженера.

Частые причины ошибки в fstab, если разложить по частоте:

• Опечатка в UUID при копировании (лишний или пропущенный символ, скопирован UUID соседнего раздела).
• Диск, который был подключён на момент правки, физически отсоединён или отвалился до перезагрузки.
• Сетевая точка монтирования (NFS/CIFS) недоступна на старте сети — сеть ещё не поднялась, а fstab уже пытается смонтировать шару.
• Раздел переименован или пересобран (после смены RAID, замены диска, миграции на другой том) — старый UUID больше не существует физически.
• Скопирована строка fstab с другого сервера без проверки, что устройство с таким путём или UUID вообще существует на этой машине.

Опция nofail: страховка для некритичных точек монтирования

Для точек монтирования, без которых сервер может нормально стартовать — внешние диски, дополнительные разделы под архивы, сетевые хранилища, — есть опция nofail. Она говорит systemd: если эту конкретную запись смонтировать не удалось, не блокируй из-за неё загрузку остальной системы, просто пропусти и иди дальше.

UUID=3a1f0c9e-8b2d-4e11-9c77-1a2b3c4d5e6f  /data/archive  ext4  defaults,nofail  0  2
/dev/sdb1  /mnt/backup  ext4  defaults,nofail  0  2
storage-nas:/exports/data  /mnt/nas  nfs  defaults,nofail,_netdev  0  0

Для сетевых файловых систем (NFS, CIFS) вместе с nofail практически всегда нужна ещё и опция _netdev — она говорит systemd, что эта точка монтирования зависит от сети, и монтировать её нужно только после того, как сеть поднялась, а не в самом начале загрузки. Без _netdev монтирование NFS может стартовать раньше сетевого интерфейса и упасть с ошибкой даже при полностью корректной конфигурации.

Важный нюанс: nofail — это не «игнорируй ошибки молча». Загрузка продолжится, но точка монтирования останется пустой директорией, и приложение, которое ожидало найти там данные, получит либо ошибку, либо запишет файлы прямо в корневой раздел (если директория существует, но ничего не смонтировано, — это отдельная классическая проблема, из-за которой диск неожиданно заполняется). Поэтому nofail стоит сочетать с проверкой в мониторинге, что нужный том действительно смонтирован, а не полагаться на то, что «раз сервер загрузился — значит всё в порядке».

Для корневого раздела, /boot и любых точек монтирования, без которых сервис физически не может работать (например, отдельный раздел с базой данных на выделенном сервере), nofail ставить не стоит — если БД без своего раздела работать не должна, лучше явный emergency mode, чем тихий старт с потерянными данными.

Таблица опций, которые чаще всего имеют значение в fstab на боевом сервере:

Как проверить fstab перед перезагрузкой, не рискуя сервером

Главное практическое правило: никогда не проверяйте правки в fstab перезагрузкой. Есть команда, которая делает то же самое, что и загрузка, но без риска потерять доступ к серверу:

sudo mount -a

Эта команда пытается смонтировать все записи из текущего /etc/fstab, которые ещё не смонтированы, — ровно то же самое, что делает система при старте. Если в конфиге опечатка, несуществующий UUID или недоступная сетевая шара, вы увидите ошибку сразу же, в интерактивной сессии, где можно тут же исправить строку и повторить команду:

$ sudo mount -a
mount: /data: can't find UUID=3a1f0c9e-8b2d-4e11-9c77-1a2b3c4d5e6f.

Если mount -a отработала без ошибок — с высокой вероятностью следующая перезагрузка тоже пройдёт штатно. Это не стопроцентная гарантия (порядок инициализации при полной загрузке чуть отличается — например, сеть на реальном старте поднимается позже, чем в уже работающей системе), но подавляющее большинство ошибок — опечатки в UUID, несуществующие устройства, неверные пути — mount -a ловит мгновенно.

Дополнительно полезно перед правкой fstab:

lsblk -f          # список блочных устройств с их UUID и точками монтирования
blkid             # UUID и метки всех разделов, которые видит система
findmnt --verify  # начиная с util-linux 2.35+ — валидирует fstab на предмет очевидных проблем

findmnt --verify стоит запускать первым — он статически проверяет синтаксис и находит часть проблем (несуществующие точки монтирования, дублирующиеся записи) ещё до попытки реального монтирования.

Ещё один рабочий приём — тестировать на копии перед боевым сервером. Если это виртуальная машина, разверните такую же на VPS или тестовом окружении, накатите ту же правку, перезагрузите её — и только убедившись, что всё поднялось штатно, переносите изменение на прод. Для критичной инфраструктуры пять минут на тестовый прогон обычно дешевле часа простоя.

Что делать, если сервер уже завис в emergency shell

Если правка уже применена и перезагрузка не удалась, а физического доступа нет, порядок действий такой:

1. Проверьте в панели провайдера, есть ли IPMI, KVM-over-IP или serial console — у большинства выделенных серверов и части VPS такой доступ предусмотрен именно для подобных случаев.
2. Через консоль войдите в emergency shell под root (пароль обычно спрашивается, если задан root-пароль системы) или, если пароль неизвестен, загрузитесь через recovery-режим GRUB с параметром init=/bin/bash — это позволяет получить доступ к корневой файловой системе без применения всех юнитов systemd.
3. Смонтируйте корень на запись (mount -o remount,rw /) и откройте /etc/fstab — либо удалите проблемную строку, либо добавьте nofail, либо исправьте UUID командой blkid.
4. Перезагрузитесь и проверьте mount -a перед тем, как закрывать сессию.

Если консольного доступа нет вообще — единственный путь это тикет в поддержку хостинга с просьбой подключиться к серверу физически или через provider-side KVM и внести правку. Именно поэтому наличие удалённого доступа к консоли стоит проверять заранее, а не в момент, когда сервер уже недоступен — подробнее о том, зачем такой доступ нужен и как он устроен на уровне железа, в статье про IPMI и удалённое управление сервером.

Почему это вообще так спроектировано

Может показаться, что поведение по умолчанию — останавливать всю загрузку из-за одной точки монтирования — избыточно строгое. Но с точки зрения разработчиков systemd логика обоснована: если приложение ожидает найти данные в /data, а вместо этого при отсутствии монтирования там просто окажется пустая директория корневого раздела, — молчаливый старт может привести к куда более серьёзным последствиям, чем недоступность сервера. Например, к тому, что база данных примет пустую директорию за чистый старт и перезапишет структуру, которая на самом деле хранилась на несмонтированном томе.

Поэтому nofail — это не «сделай systemd менее строгим», а осознанное решение администратора: «эта конкретная точка монтирования не критична для старта системы, для неё безопаснее продолжить загрузку, чем остановить всё». Для корня, /boot, разделов под СУБД такое решение принимать не стоит — там правильнее явный отказ и ручной разбор, чем тихий старт в неполном состоянии. О том, как вообще устроена очерёдность и зависимости юнитов при старте системы, подробнее в статье как работает systemd при загрузке.

Если после правки конфигов сервер всё равно перезагружается заметно дольше обычного (даже без падения в emergency shell) — это может быть тот же таймаут ожидания устройства, только в мягкой форме: система в итоге стартует, но тратит на попытки монтирования лишние секунды или минуты. Разбор похожих случаев — в статье перезагрузка растянулась на час.

Частые вопросы