Как проверить fstab до перезагрузки: findmnt без mount -a

Для Ubuntu 24.04 подходит findmnt из util-linux. Команда с --verify разбирает таблицу, проверяет её пригодность и возвращает ненулевой код при найденной ошибке. Параметр --tab-file позволяет указать копию, не заменяя /etc/fstab и не выполняя монтирование.

Ниже проверяется синтаксис и доступная системе информация о цели и источнике. Это не доказательство, что файловая система исправна, сетевое хранилище будет доступно при загрузке, пароль для CIFS верен или приложение переживёт смену точки монтирования. Команда ничего не монтирует и не воспроизводит загрузку systemd.

Проверка выполнена 7 октября 2026 года в изолированной Ubuntu 24.04.3 с util-linux 2.39.3. Использованы только каталоги и учебные файлы в рабочей директории; /etc/fstab не изменялся, mount и перезагрузка не запускались.

findmnt --version

В проверенной среде результат проверки версии: findmnt from util-linux 2.39.3. Возможности и формулировки диагностики в другой версии могут отличаться.

cp /etc/fstab ./fstab.candidate

Редактируйте только fstab.candidate. Если источником изменения служит система управления конфигурацией, сформируйте кандидат тем же шаблоном, который будет применён на сервере: ручная копия и производимый автоматикой файл могут отличаться.

findmnt --verify --verbose --tab-file ./fstab.candidate

Код 0 означает, что findmnt не нашёл ошибок и предупреждений в доступной ему проверке. Это не разрешение на автоматическую перезагрузку. Код 1 требует прочитать диагностику, исправить кандидат и повторить ту же команду.

Документация findmnt указывает: --verify проверяет разбираемость и пригодность таблицы, а --tab-file подменяет путь к проверяемому файлу. Там же сказано, что --verbose добавляет детали, а код 1 используется при ошибке.

В первом тесте точка монтирования существовала, а bind-источник был доступен. Проверка завершилась сообщением Success, no errors or warnings detected и кодом 0.

findmnt --verify --verbose --tab-file ./fstab-valid; echo $?

Во втором тесте в строке был указан несуществующий каталог назначения. findmnt сообщил unreachable on boot required target и вернул 1. Такой результат важен даже при корректном числе полей: строка формально читается, но применить её как обязательное монтирование нельзя.

findmnt --verify --verbose --tab-file ./fstab-bad-target; echo $?

Третий тест использовал UUID, которого нет в среде. Диагностика сообщила unreachable on boot required source и вернула 1. Это проверка доступности тега на текущем узле, а не состояния файловой системы внутри устройства.

findmnt --verify --verbose --tab-file ./fstab-bad-source; echo $?

Строка из одного поля дала parse error at line 1 -- ignored и код 1. А строка без пятого и шестого полей прошла с кодом 0: это не пропуск проверки. Для fs_freq и fs_passno документация определяет значения по умолчанию, поэтому их отсутствие не считается синтаксической ошибкой.

Формат шести полей, экранирование пробелов и значения по умолчанию описаны в справке fstab. Особенно проверьте второй столбец — точку монтирования — и идентификатор источника в первом.

После кода 0 сопоставьте кандидат с фактическими устройствами. Для UUID и LABEL важна не похожая строка, а разрешение тега в нужное устройство.

findmnt --fstab --evaluate --tab-file ./fstab.candidate --output=SOURCE,TARGET,FSTYPE,OPTIONS

Затем отдельно проверьте, существует ли ожидаемый каталог, какой у него владелец и не скрывает ли новое монтирование уже лежащие там данные. findmnt подтвердит существование цели, но не решит, должны ли находящиеся в каталоге файлы оставаться видимыми после монтирования.

mount -a пытается выполнить операции из fstab, кроме записей с noauto. Это изменение состояния: оно может подключить сетевой ресурс, скрыть содержимое каталога новым монтированием или запустить файлово-системные помощники. Использовать такую команду только ради синтаксической проверки не стоит.

• Сохранить кандидат отдельно от /etc/fstab и зафиксировать исходную конфигурацию.

• Проверить версию util-linux.

• Запустить findmnt --verify --verbose с явным --tab-file.

• Исправить каждую ошибку и предупреждение; не ориентироваться только на текст Success.

• Проверить, в какие устройства преобразуются UUID и LABEL при вызове findmnt --fstab --evaluate.

• Сопоставить источник, цель, тип и опции с планом изменения.

• После штатного применения снова проверить уже /etc/fstab.

• Реальное монтирование и перезагрузку проводить только с планом отката и доступом к консоли.

Итоговый вопрос перед перезагрузкой звучит не «команда была зелёной?», а «какой источник смонтируется в какую цель, с какими опциями и как я верну систему, если загрузка пойдёт иначе?». findmnt закрывает первую часть этого вопроса; план восстановления и испытание сервиса остаются обязанностью команды.

Ubuntu 24.04 is compatible with findmnt from util-linux. The command with --verify parses the table, checks its suitability, and returns a non-zero code if an error is found. The --tab-file parameter allows specifying a copy without replacing /etc/fstab or performing mounting.

Below, syntax and system-available information about the target and source are checked. This is not proof that the file system is correct, the network storage will be accessible at boot, the password for CIFS is valid, or that the application will survive a mount point change. The command performs no mounting and does not reproduce the boot of systemd.

The check was performed on October 7, 2026, in an isolated Ubuntu 24.04.3 with util-linux 2.39.3. Only directories and sample files in the working directory were used; /etc/fstab was not modified, and mount and the reboot were not triggered.

findmnt --version

In the checked environment, the version check result is: findmnt from util-linux 2.39.3. Capabilities and diagnostic phrasing may differ in other versions.

cp /etc/fstab ./fstab.candidate

Edit only fstab.candidate. If the source of the change is a configuration management system, generate the candidate using the same template that will be applied on the server: a manual copy and the file produced by automation may differ.

findmnt --verify --verbose --tab-file ./fstab.candidate

Code 0 means that findmnt found no errors or warnings in the available check. This is not authorization for an automatic reboot. Code 1 requires reading the diagnostics, fixing the candidate, and repeating the same command.

findmnt documentation states: --verify checks table readability and suitability, while --tab-file substitutes the path to the file being checked. It also states that --verbose adds details, and code 1 is used in case of an error.

In the first test, the mount point existed and the bind source was accessible. The check completed with the message Success, no errors or warnings detected and code 0.

findmnt --verify --verbose --tab-file ./fstab-valid; echo $?

In the second test, the destination directory specified in the line did not exist. findmnt reported unreachable on boot required target and returned 1. This result is important even with the correct number of fields: the line is formally readable, but it cannot be applied as a mandatory mount.

findmnt --verify --verbose --tab-file ./fstab-bad-target; echo $?

The third test used UUID, which does not exist in the environment. Diagnostics reported unreachable on boot required source and returned 1. This checks for the availability of the tag on the current node, not the state of the file system inside the device.

findmnt --verify --verbose --tab-file ./fstab-bad-source; echo $?

A single-field line returned parse error at line 1 -- ignored and code 1. A line without the fifth and sixth fields passed with code 0: this is not a skipped check. For fs_freq and fs_passno, the documentation defines default values, so their absence is not considered a syntax error.

The six-field format, space escaping, and default values are described in the fstab reference. Pay special attention to the second column—the mount point—and the source identifier in the first.

After code 0, match the candidate against actual devices. For UUID and LABEL, it is not a similar string that matters, but resolving the tag to the correct device.

findmnt --fstab --evaluate --tab-file ./fstab.candidate --output=SOURCE,TARGET,FSTYPE,OPTIONS

Then separately verify whether the expected directory exists, who owns it, and whether the new mount hides data already present there. findmnt will confirm the target exists, but it will not determine whether files in the directory should remain visible after mounting.

mount -a attempts to perform operations from fstab, except for entries with noauto. This state change can mount a network resource, hide directory contents with a new mount, or trigger file system helpers. Do not use such a command solely for syntax checking.

• Save the candidate separately from /etc/fstab and record the initial configuration.

• Check the version of util-linux.

• Run findmnt --verify --verbose with an explicit --tab-file.

• Fix every error and warning; do not rely only on the Success text.

• Check which devices UUID and LABEL convert to when calling findmnt --fstab --evaluate.

• Match the source, target, type, and options against the change plan.

• After standard application, check /etc/fstab again.

• Perform actual mounting and rebooting only with a rollback plan and console access.

The final question before rebooting is not 'Was the command green?', but 'which source mounts to which target, with what options, and how do I restore the system if the boot proceeds differently?'. findmnt addresses the first part of this question; the recovery plan and service testing remain the team's responsibility.