fstab¶

Файл /etc/fstab задаёт постоянное подключение файловых систем при загрузке. НАЙС.ОС CLOUD использует systemd, который переводит записи fstab в объекты монтирования и выстраивает зависимости запуска. Ошибка в обязательном монтировании может отправить сервер в аварийный режим, поэтому проверять конфигурацию надо до перезагрузки.

Определение файловой системы¶

lsblk -f
blkid
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Пример вывода blkid:

/dev/vdb1: UUID="12345678-1234-1234-1234-123456789abc" TYPE="ext4"

UUID в примере вымышленный. Никогда не копируйте его в реальную конфигурацию. Получите значение своего устройства.

Четыре поля и дополнительные параметры¶

Классическая строка /etc/fstab содержит шесть полей: источник, точка монтирования, тип ФС, параметры, dump и pass. Например:

# Образец для существующей ФС ext4; замените UUID реальным
UUID=12345678-1234-1234-1234-123456789abc /srv/data ext4 defaults,nofail 0 2

nofail позволяет загрузке продолжиться при отсутствии устройства, но не делает потерю данных безопасной для приложения. Если сервис зависит от /srv/data, ему нужны собственные проверки и зависимости. Для critical data nofail может скрывать серьёзную проблему, поэтому выбор этой опции должен быть осознанным.

Безопасная процедура добавления готовой ФС¶

Подтвердите идентификатор ФС (blkid), убедитесь, что том не смонтирован поверх чужих данных.
Сделайте резервную копию /etc/fstab с датой и проверьте содержимое файла.
Создайте пустой каталог точки монтирования с нужными правами.
Добавьте ровно одну строку с UUID=.
Выполните findmnt --verify --verbose и systemctl daemon-reload.
Выполните целевое монтирование mount /srv/data и findmnt /srv/data.
Убедитесь, что файловая система соответствует нужному UUID, и только потом проверьте перезагрузку при наличии аварийной консоли.

Команды:

cp -a /etc/fstab "/root/fstab.$(date +%Y%m%d-%H%M%S).bak"
findmnt --verify --verbose
systemctl daemon-reload
mount /srv/data
findmnt /srv/data

Убедитесь, что каталог /srv/data и запись fstab уже корректны. mount /srv/data не следует применять к непроверенному диску.

Почему нельзя просто выполнить `mount -a`¶

mount -a попытается смонтировать все несмонтированные записи fstab, что может вызвать побочные эффекты на продакшн-сервере. Для первичной проверки отдельного нового тома целевое mount /srv/data безопаснее и предсказуемее.

Особые случаи¶

Btrfs: subvol= и subvolid= меняют используемый подтом.
XFS: проверка/восстановление проводится специфичными средствами XFS, а не e2fsck.
Сетевые ФС NFS/CIFS: нужны _netdev и согласование зависимостей/таймаутов.
Шифрование: зависимость от crypttab и доступность ключей при старте.
Root FS: настройка может зависеть от initramfs, загрузчика и режима образа.

Восстановление после ошибки¶

Откройте консоль, найдите проблему через journalctl -xb и systemctl --failed, восстановите резервную копию fstab, выполните повторную проверку. Не применяйте fsck -y к неизвестной файловой системе и не «лечите» ошибку UUID форматированием диска.

Источники: systemd.mount, systemd-fstab-generator.