Гайд: Astra Linux: CIFS‑шара не монтируется при загрузке (сеть поднимается позже) - Часть 1

Как настроить автоматическое монтирование CIFS в Astra Linux, если сеть поднимается позже. Решения через fstab, systemd-automount и autofs без ошибок загрузки.

2026.11.14                  

Гайд: Astra Linux: CIFS‑шара не монтируется при загрузке (сеть поднимается позже) - Часть 1Гайд: Astra Linux: CIFS‑шара не монтируется при загрузке (сеть поднимается позже) - Часть 1

0. TL;DR — рабочее решение за 2 минуты

В /etc/fstab вместо обычного монтирования используйте автомонтирование по первому обращению + явную привязку к сети:

//192.168.1.10/share  /mnt/share  cifs  credentials=/etc/cifs/share.cred,vers=3.0,iocharset=utf8,uid=1000,gid=1000,file_mode=0664,dir_mode=0775,noserverino,soft,_netdev,nofail,noauto,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.mount-timeout=30s,x-systemd.requires=network-online.target,x-systemd.after=network-online.target  0  0

sudo systemctl daemon-reload
sudo systemctl restart remote-fs.target
sudo systemctl start mnt-share.automount
ls /mnt/share        # монтирование произойдёт здесь, а не на старте системы

Смысл:

Загрузка не ждёт сеть и не падает, а шара монтируется в момент первого обращения (когда сеть уже точно есть). Если нужен именно «монтирован сразу после загрузки» — смотрите варианты B/C/D.

1. Почему это происходит

Как systemd обрабатывает fstab

systemd-fstab-generator превращает каждую строку fstab в юнит *.mount:

Признак в fstab Куда попадает юнит Порядок запуска
обычная строка local-fs.target до сети, очень рано
есть _netdev (или fstype cifs/nfs) remote-fs.target After=network-online.target, Wants=network-online.target

Т.е. _netdev — обязательный минимум. Но его недостаточно, и вот почему.

Главная ловушка: network-online.target — это фикция без wait-online

network-online.target — пассивная цель.

Она считается «достигнутой» только если кто-то реально умеет ждать сеть:

  • NetworkManager-wait-online.service (NetworkManager);
  • systemd-networkd-wait-online.service (systemd-networkd);
  • networking.service (ifupdown, /etc/network/interfaces) — он имеет WantedBy=network-online.target.

Если соответствующая служба выключена — таргет достигается мгновенно, ещё до появления IP. Монтирование стартует, получает Network is unreachable и падает. Классика.

Другие реальные причины (по частоте)

  1. wait-online не включён (см. выше) — 60% случаев.
  2. allow-hotplug eth0 вместо auto eth0 в /etc/network/interfaces: ifup -a поднимает только auto, network-online.target проходит «пустым».
  3. DHCP/DNS дольше, чем таймаут wait-online (по умолчанию 30 с), либо коммутатор с STP (порт «молчит» первые ~30 с), VLAN, bonding, 802.1X, Wi‑Fi.
  4. Wi‑Fi/соединение NM с паролем в keyring пользователя (psk-flags=1, connection.permissions=user:...) — сеть поднимается только после графического логина. Никакой fstab тут не поможет, пока соединение не станет системным.
  5. Имя сервера не резолвится на раннем этапе (DNS ещё не доступен, nss-lookup.target не отработан) → mount error(2) / could not resolve address.
  6. Нет _netdev/nofail → юнит уходит в local-fs.target, падает и может уронить загрузку в emergency mode.
  7. Нет cifs-utils → bad option; ... you might need a /sbin/mount.<type> helper.
  8. Файл credentials лежит на сетевом/отдельном разделе (/home/...), который ещё не смонтирован.
  9. Неверные vers=/sec= — сеть тут вообще ни при чём, но симптом «при загрузке не монтируется» тот же (руками тоже не монтируется — проверяйте!).

2. Диагностика: ставим точный диагноз

# Кто управляет сетью?
systemctl is-active NetworkManager systemd-networkd networking
systemctl is-enabled NetworkManager-wait-online.service systemd-networkd-wait-online.service

# Имя юнита для точки монтирования
systemd-escape -p --suffix=mount /mnt/share      # → mnt-share.mount

# Что случилось при загрузке
systemctl status mnt-share.mount mnt-share.automount
journalctl -b -u mnt-share.mount -u mnt-share.automount --no-pager
journalctl -b -o short-monotonic | grep -Ei 'cifs|network-online|wait-online|mnt-share'

# Реальный порядок и зависимости
systemd-analyze critical-chain mnt-share.mount
systemctl show mnt-share.mount -p After -p Wants -p Options -p Where
systemd-analyze plot > /tmp/boot.svg      # наглядная картина загрузки

# Проверка синтаксиса fstab
findmnt --verify --verbose

# Ядро/клиент CIFS
dmesg | grep -i cifs
cat /proc/fs/cifs/DebugData
modinfo cifs | head -3

Ручная проверка (обязательно!)

sudo mount -t cifs //192.168.1.10/share /mnt/test \
  -o credentials=/etc/cifs/share.cred,vers=3.0,iocharset=utf8

Если руками не монтируется — проблема не в загрузке, а в опциях/доступе (см. таблицу ошибок в §12).

3. Подготовка

sudo apt update
sudo apt install cifs-utils keyutils      # keyutils нужен для DFS/Kerberos (cifs.upcall)
sudo mkdir -p /mnt/share /etc/cifs

Файл учётных данных (никогда не пишите пароль в fstab — он виден в mount, /proc/mounts, журналах):

sudo tee /etc/cifs/share.cred >/dev/null <<'EOF'
username=ivanov
password=P@ssw0rd,с запятой тоже можно
domain=CORP
EOF
sudo chmod 600 /etc/cifs/share.cred
sudo chown root:root /etc/cifs/share.cred

Файл должен быть в корневого раздела (/etc), без BOM и CRLF (не редактируйте блокнотом Windows), без пробелов вокруг =.

Проверьте, что права на точку монтирования и uid/gid соответствуют вашему пользователю: id -u, id -g.

4. Вариант A (рекомендуемый): fstab + x-systemd.automount

Самый устойчивый к «сеть позже» способ: загрузка не блокируется, монтирование ленивое.

//192.168.1.10/share /mnt/share cifs credentials=/etc/cifs/share.cred,vers=3.0,iocharset=utf8,uid=1000,gid=1000,file_mode=0664,dir_mode=0775,noserverino,soft,echo_interval=10,_netdev,nofail,noauto,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.mount-timeout=30s,x-systemd.requires=network-online.target,x-systemd.after=network-online.target 0 0

Что делает каждая «системная» опция:

Опция Эффект
_netdev относит монтирование к remote-fs.target, добавляет зависимость от сети
nofail сбой монтирования не ломает загрузку (не будет emergency mode)
noauto + x-systemd.automount создаётся mnt-share.automount; монтирование — по первому доступу к /mnt/share
x-systemd.idle-timeout=60 автомонтирование отмонтирует шару после 60 с простоя (лечит «залипшие» маунты)
x-systemd.mount-timeout=30s таймаут самой операции монтирования
x-systemd.requires= / after= жёсткая привязка к network-online.target (одного after недостаточно — он не «тянет» таргет)

Применение:

sudo systemctl daemon-reload
sudo systemctl restart remote-fs.target
sudo systemctl start mnt-share.automount
systemctl status mnt-share.automount        # active (waiting)
ls /mnt/share && findmnt /mnt/share

Нюансы:

  • Точка монтирования должна существовать; не держите её открытой в файловом менеджере/терминале — иначе idle-таймаут не сработает.
  • Пробелы и кириллицу в путях лучше не использовать; при необходимости пробел кодируется как \040.
  • Не путайте x-systemd.mount-timeout (для сетевых ФС) и x-systemd.device-timeout (для блочных устройств) — второй для CIFS бесполезен.

5. Вариант B: заставить network-online.target действительно ждать сеть

Нужен, если шара обязана быть смонтирована до старта прикладных сервисов (БД, 1С, бэкап).

5.1 NetworkManager (типовой для Astra с графикой Fly)

sudo systemctl enable --now NetworkManager-wait-online.service
systemctl status NetworkManager-wait-online.service

Увеличить таймаут (DHCP/STP/Wi‑Fi):

sudo systemctl edit NetworkManager-wait-online.service

[Service]
ExecStart=
ExecStart=/usr/bin/nm-online -s -q --timeout=90

Сделать соединение системным и «обязательным» (иначе wait-online его не ждёт):

nmcli -f NAME,UUID,TYPE,DEVICE,AUTOCONNECT con show
sudo nmcli con mod "Проводное соединение 1" connection.autoconnect yes
sudo nmcli con mod "Проводное соединение 1" connection.permissions ""     # не привязывать к пользователю
sudo nmcli con mod "Проводное соединение 1" ipv4.may-fail no
sudo nmcli con mod "Проводное соединение 1" ipv6.may-fail no              # если IPv6 не используется
# Wi-Fi: хранить пароль в системе, а не в keyring
sudo nmcli con mod "MyWiFi" wifi-sec.psk-flags 0 wifi-sec.psk "пароль"

Для сервера надёжнее статика: ipv4.method manual ipv4.addresses 192.168.1.50/24 ipv4.gateway 192.168.1.1 ipv4.dns 192.168.1.1.

5.2 systemd-networkd

sudo systemctl enable --now systemd-networkd-wait-online.service
sudo systemctl cat systemd-networkd-wait-online.service   # узнать реальный путь к бинарнику
sudo systemctl edit systemd-networkd-wait-online.service

[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --interface=eth0 --timeout=90

(--any — достаточно любого интерфейса; без параметров служба ждёт все управляемые интерфейсы и может «висеть».) В .network-файле проблемные интерфейсы помечайте RequiredForOnline=no.

5.3 ifupdown / /etc/network/interfaces (частый серверный вариант Astra)

auto lo
iface lo inet loopback

auto eth0                      # именно auto, НЕ allow-hotplug!
iface eth0 inet static
    address 192.168.1.50/24
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1

sudo systemctl enable networking.service
sudo systemctl restart networking

networking.service сам участвует в network-online.target. Убедитесь, что NetworkManager не «дерётся» за тот же интерфейс (/etc/NetworkManager/NetworkManager.conf, секция [ifupdown] managed=false, либо интерфейс в unmanaged-devices).

5.4 Проблема DNS

Если в UNC указано имя — на раннем этапе оно может не резолвиться.

Варианты:

  • использовать IP в fstab (самое надёжное);
  • прописать в /etc/hosts: 192.168.1.10 filesrv filesrv.corp.local;
  • добавить x-systemd.after=nss-lookup.target.

Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.

Статью подготовил: Аверко Денис Сергеевич @Nymexis г. Омск (специалист по ЗИ)
×

Полный размер Слайдшоу Предыдущий Следующий

Комментарии

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