Увеличить время отведенное на монтирование сетевых папок

[ogankvik]

Добрый день!
1. Linux Mint 19.3 x64.
2. Cinnamon
4. Как настроено монтирование сетевых папок: включаешь ПК и ОС загружается с уже примонтированными сетевыми папками. Монтирование настроено через fstab (конфиг ниже). Проблемы возникают если развернуть линукс в другом здании, на расстоянии сотни метров, медиаконвертора и пары свичей. Там папки не хотят монтироваться. Если в загруженной системе сделать sudo mount -a, то они монтируются!

Как можно увеличить время отведенное на монтирование сетевых папок? Думаю, дело в том что линукс бросает попытку их монтирования слишком быстро. Есть еще вариант запихнуть sudo mount -a в /etc/systemd/system/certupdt.service и и делать ему запуск с системой, но хотелось бы разобраться с монтированием через fstab.

С сетью вродебы всё норм. Пакеты не теряются, задержка <1мс.

Содержимое /etc/fstab:

Код: Выделить всё

//192.168.3.1/обменник /mnt/обменник cifs ,user=anonymous,password=,dom=,rw,noexec,nobrl,iocharset=utf8,gid=1000,uid=1000,nounix,file_mode=0777,dir_mode=0777,_netdev 0 0

[slant]

Как можно увеличить время отведенное на монтирование сетевых папок? Думаю, дело в том что линукс бросает попытку их монтирования слишком быстро.

Проблема не совсем в этом. Монтирование через fstab не учитывает параллельный старт сервисов через systemd, и сервис/задача монтирования файловых систем (к которой относится fstab) запросто может запуститься и отработать раньше чем задача настройки сети. Потому и происходит такая ерунда. Причем на уровне fstab это не лечится в принципе, т.к. нельзя ставить жесткую зависимость задачи монтирования файловых систем от задачи подъема сети. Опция _netdev теоретически должна это предотвращать, но на практике - ее не достаточно. Можно попробовать добавить еще опцию x-systemd.automount - но тоже не всегда помогает.

Правильных (рабочих) вариантов два:
1. Использование отдельного юнита systemd с автомонтированием cifs (есть такая фича).
2. Восстановление legacy /etc/rc.local и запихивание туда скрипта с проверкой/ожиданием наличия сети монтированием сетевых ресурсов. Костыль, но рабочий и надежный.

Но идеологически правильный для современных систем - вариант 1.
Примерно так: https://www.hippolab.ru/systemd-automount как основа.
Или вот тут: http://yar4e-it.blogspot.com/2014/09/sy ... -cifs.html подробнее.
Обратите внимание на наличие строчек:
Requires=network-online.target
After=network-online.service
во втором случае - они осуществляют контроль за последовательностью старта.

[ogankvik]

slant , большое спасибо за развернутый ответ! Попробовал по быстрому второй способ - папки не монтируются. Видимо, я допустил ошибки, но не было времени разбираться. Неделя начнется - займусь. Благодаря вашему посту переведу взаимодействие пк с сетью на более правильный уровень.

[ogankvik]

В общем, остановился на первом способе (https://www.hippolab.ru/systemd-automount). Но не могу победить ошибку "share.mount: Where= setting doesn't match unit name. Refusing."
Как делал:

Код: Выделить всё

sudo touch /lib/systemd/system/share.mount

Код: Выделить всё

sudo xed /lib/systemd/system/share.mount

Вставил в него:

Код: Выделить всё

[Unit]
Description=Mount point for cifs
 
[Mount]
What=//192.168.3.1/обменник
Where=/mnt/obmennik
Type=cifs
Options=user=anonymous,password=,dom=,rw,noexec,nobrl,iocharset=utf8,gid=1000,uid=1000,nounix,file_mode=0777,dir_mode=0777,_netdev 0 0

/mnt/obmennik - ранее была создана с правами на чтение/запись пользователю

Код: Выделить всё

sudo systemctl daemon-reload

Код: Выделить всё

sudo systemctl start share.mount
Failed to start share.mount: Unit share.mount is not loaded properly: Invalid argument.
See system logs and 'systemctl status share.mount' for details.

Код: Выделить всё

journalctl -u share.mount
-- Logs begin at Fri 2020-11-13 12:34:01 MSK, end at Sun 2023-11-19 15:28:38 MSK. --
дек 21 15:52:24 user-desktop systemd[1]: share.mount: Where= setting doesn't match unit name. Refusing.
дек 21 15:52:40 user-desktop systemd[1]: share.mount: Where= setting doesn't match unit name. Refusing.

[symon2014]

Failed to start share.mount: Unit share.mount is not loaded properly: Invalid argument.

https://www.thegeekdiary.com/failed-to- ... g-systemd/

[ogankvik]

То есть, путь к файлу должен быть /lib/systemd/system/mnt-share.mount ? Это было не просто понять..

[ogankvik]

Но идеологически правильный для современных систем - вариант 1.
Примерно так: https://www.hippolab.ru/systemd-automount как основа.

После нескольких попыток удалось его повторить. Очень понравился, лучше чем монтирование через запись в fstb. НО, есть один нюанс. Почему-то при первом открытии, примонтированная сетевая папка и все вложенные файлы принадлежат руту! Стоит нажать F5, или переоткрыть ее - и пользователь меняется с root на текущего (user). Не могу понять почему так происходит. Да, если монтировать не в /mnt, а /home, то такой проблемы нет, но на рабочем столе появляется примонтированная папка, а она там совсем не нужна.

Как исправить права на файлы при первом открытии или скрыть сетевую папку с рабочего стола (пробовал штатным средствами, но вместе с сетевой папкой пропадают примонтированные флешки).

Как делал:
1. Создаем mnt-userdata.mount:

Код: Выделить всё

sudo touch /lib/systemd/system/mnt-userdata.mount

2. Вставляем в него содержимое и сохраняем:

Код: Выделить всё

sudo xed /lib/systemd/system/mnt-userdata.mount

Текст:

Код: Выделить всё

[Unit]
Description=Mount point for cifs

[Mount]
What=//192.168.3.21/userdata
Where=/mnt/USERDATA
Type=cifs
Options=user=userdata,password=sdw4fsderwe,dom=,rw,noexec,nobrl,iocharset=utf8,gid=1000,uid=1000,nounix,file_mode=0777,dir_mode=0777

3. Создаем папку для монтирования:

Код: Выделить всё

sudo mkdir /mnt/userdata

4. Меняем владельца папки с root на user

Код: Выделить всё

sudo chown user:user /mnt/userdata

5. Создаем mnt-userdata.automount:

Код: Выделить всё

sudo touch /lib/systemd/system/mnt-userdata.automount

6. Вставляем в него содержимое и сохраняем:

Код: Выделить всё

sudo xed /lib/systemd/system/mnt-userdata.automount

Текст:

Код: Выделить всё

[Unit]
Description=Automount unit for cifs

[Automount]
Where=/mnt/userdata

[Install]
WantedBy=remote-fs.target 

7.Перечитать конфигурацию юнитов:

Код: Выделить всё

sudo systemctl daemon-reload

8.Добавить юнит в автозагрузку:

Код: Выделить всё

sudo systemctl enable mnt-userdata.automount

[ogankvik]

Выяснил, что проблема с правами возникает после создание юнита mnt-userdata.automount. Пока не понятно что с эти делать..

[ogankvik]

Вроде со всем разобрался кроме одного. Если во время работы отключить сетевой провод или произойдет сбой в сетевом оборудовании, приводящий к потере связи с шарой, то комп начинает тупить. Например, при открытии файлов или их сохранении он задумывается секунд на 10. Буд-то пытается восстановить связь с шарой. Как уменьшить время опроса шары, если они вдруг станет недоступна после монтирования?

[madesta]

Например, при открытии файлов или их сохранении он задумывается секунд на 10. Буд-то пытается восстановить связь с шарой.

Прошу проявить снисходительность, что отклоняюсь от темы, но ИМХО редактировать на шаре - не самый надёжный способ избежать потери вносимых изменений в данные. Лучше редактировать локально, а на шару помещать лишь уже сохранённый документ. В этом случае и вопрос уменьшения времени опроса шары как-то снимается сам собой.