Должна ли пользовательская сессия владеть монтированием SSHFS через VPN?

Монтирование общей папки после поднятия VPN затрагивает две личности, которые легко перепутать: компонент, которому разрешено настраивать сеть, и учётную запись, которой разрешено входить на файловый сервер. Они редко совпадают. Root-хук VPN — плохое место для запуска монтирования SSHFS пользователя рабочего стола, потому что у него нет ни агента пользователя, ни предполагаемого владельца монтирования. Если сначала правильно определить владельца, триггер становится простым.

Две личности, два отдельных разрешения

Клиенту VPN нужны привилегии для изменения маршрутов и интерфейсов. Монтированию SSHFS нужна личность SSH, которую принимает файловый сервер, и монтирование FUSE, принадлежащее учётной записи, которая будет читать файлы. Один скрипт, запущенный от root, выполняет первое требование и тихо нарушает второе.

Монтирование от root оставляет файлы вне сеанса рабочего стола и, возможно, без доступа к агенту, который хранит ключ пользователя. Монтирование существует, пользователь не может писать через него, а сбой выглядит как проблема прав на стороне сервера. Такой неверный диагноз стоит половины дня и заявки в команду хранения.

Решите, какая учётная запись владеет монтированием, прежде чем писать любую автоматизацию, потому что этот выбор определяет, где живёт триггер и к каким учётным данным он может добраться.

Сначала вручную создайте монтирование, принадлежащее пользователю

Начните с вошедшего пользователя с пустой точкой монтирования, авторизованной учётной записью SSH и рабочим путём к серверу через туннель. Ручное монтирование задаёт основу, которую должна воспроизвести любая автоматизация.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

Имена приведены для примера, поэтому замените хост и путь экспорта, которые ваш сервер действительно предлагает. Проверьте ключ хоста через одобренный процесс при первом подключении. Обратите внимание, что пароль учётной записи VPN не является автоматически учётными данными учётной записи хранения, и это частая причина неудачных попыток.

Запускайте как обычный пользователь с точкой монтирования, принадлежащей этому пользователю. По умолчанию только монтирующая учётная запись получает доступ к файлам, а allow_other расширяет эту границу на каждого локального пользователя. Это намеренное расширение доступа, а не обходной путь для автоматизации.

Позвольте триггеру действовать в том же контексте сеанса

Позвольте поддерживаемой интеграции событий VPN запросить выполнение действия пользовательской сессии, вместо того чтобы предполагать, что привилегированный callback может одолжить учётные данные рабочего стола. Ограничьте триггер предполагаемым идентификатором подключения, а не любым интерфейсом, который случайно называется tun0. Правило диспетчера, совпадающее с неправильной вещью, срабатывает при каждом изменении сети, включая те, что не имеют никакого отношения к этому монтированию.

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

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

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

Необслуживаемой службе нужны собственные одобренные учётные данные и собственная проверка хоста в собственном контексте выполнения. Она не может предполагать, что графический агент разблокирован, и не должна пытаться его разблокировать.

Спланируйте отключение, прежде чем форсировать очистку

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

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

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

Неожиданная потеря ведёт себя иначе. SSHFS документирует, что прерывание сети может заблокировать операцию файловой системы, а параметр reconnect восстанавливает транспорт без восстановления дескрипторов: файл, открытый до переподключения, может не записаться в следующий раз, а прерванная запись не сохраняется. Эта разница важнее всего для редакторов, которые держат один файл открытым часами. Спланируйте шаг повторного открытия, а не полагайтесь на восстановление.

Проверьте поведение на одноразовых файлах, прежде чем полагаться на него. Папка, которая снова появляется после возвращения туннеля, не доказывает, что прежние дескрипторы или несохранённая работа выжили.