A sessão do usuário deve possuir a montagem SSHFS sobre VPN?

Montar uma pasta compartilhada depois que a VPN sobe envolve duas identidades fáceis de confundir: o componente autorizado a configurar a rede e a conta autorizada a entrar no servidor de arquivos. Raramente são a mesma. Um hook VPN pertencente ao root é um mau lugar para iniciar a montagem SSHFS de um usuário de desktop, porque não tem nem o agente do usuário nem a propriedade de montagem pretendida. Acertar a propriedade primeiro torna o gatilho simples.

Duas identidades, duas permissões separadas

O cliente VPN precisa de privilégios para alterar rotas e interfaces. A montagem SSHFS precisa de uma identidade SSH aceita pelo servidor de arquivos e de uma montagem FUSE pertencente à conta que lerá os arquivos. Um único script executado como root atende ao primeiro requisito e quebra silenciosamente o segundo.

Montar como root deixa os arquivos fora da sessão de desktop e possivelmente sem acesso ao agente que guarda a chave do usuário. A montagem existe, o usuário não consegue escrever por ela, e a falha parece um problema de permissões do servidor. Esse diagnóstico errado custa uma tarde e um chamado para a equipe de armazenamento.

Decida qual conta possui a montagem antes de escrever qualquer automação, porque essa escolha determina onde o gatilho vive e a quais credenciais ele pode chegar.

Primeiro estabeleça manualmente uma montagem pertencente ao usuário

Comece com um usuário conectado com um ponto de montagem vazio, uma conta SSH autorizada e um caminho funcional até o servidor pelo túnel. Uma montagem manual estabelece a linha de base que qualquer automação deve reproduzir.

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

Os nomes são exemplos, então substitua o host e o caminho de exportação que o seu servidor realmente oferece. Verifique a chave do host pelo processo aprovado nessa primeira conexão. Observe que a senha da conta VPN não é automaticamente a credencial da conta de armazenamento, e essa é uma causa comum de tentativas falhas.

Execute-o como usuário comum com um ponto de montagem pertencente a esse usuário. Por padrão, apenas a conta que monta chega aos arquivos, e allow_other amplia essa fronteira para cada usuário local. Isso é uma ampliação deliberada do acesso, não uma solução alternativa para a automação.

Faça o gatilho agir no mesmo contexto de sessão

Deixe a integração de eventos VPN suportada pedir a execução de uma ação da sessão do usuário, em vez de presumir que um callback privilegiado pode tomar emprestada uma credencial de desktop. Limite o gatilho ao identificador de conexão pretendido e não a qualquer interface que por acaso se chame tun0. Uma regra de despachante que corresponde à coisa errada dispara a cada mudança de rede, incluindo as que não têm nada a ver com esta montagem.

A ação deve confirmar o nome de host esperado, notar uma montagem existente e fazer uma tentativa limitada. Um laço de sondagem que inicia um novo processo SSHFS a cada poucos segundos, ou repete um pedido de credenciais enquanto o servidor está fora, transforma uma interrupção curta em um monte de processos travados. Limite a tentativa com um tempo limite e uma única nova tentativa.

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

O primeiro comando fornece o identificador de conexão que o despachante deve corresponder. Os outros dois mostram se uma tentativa já está em andamento, e essa é a verificação que evita duplicatas.

Um serviço sem supervisão precisa de suas próprias credenciais aprovadas e de sua própria verificação de host em seu próprio contexto de execução. Ele não pode presumir que um agente gráfico esteja desbloqueado, e não deve tentar desbloquear um.

Planeje a desconexão antes de forçar a limpeza

Para uma desconexão planejada, conclua as operações de arquivo e desmonte a partir do próprio fluxo de trabalho do usuário que monta. Mire no ponto de montagem e não no processo, e confirme o resultado antes de relatar sucesso.

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

Desmonte apenas a montagem criada por este fluxo de trabalho. Se estiver ocupada, é uma decisão da aplicação: uma separação forçada que existe para fazer um hook retornar sucesso esconde a perda de dados em vez de evitá-la.

A perda inesperada se comporta de forma diferente. O SSHFS documenta que uma interrupção de rede pode bloquear uma operação do sistema de arquivos, e a opção reconnect restaura o transporte sem restaurar os handles: um arquivo aberto antes da reconexão pode falhar na próxima escrita, e uma escrita interrompida não é preservada. Essa distinção importa mais para editores que mantêm um arquivo aberto por horas. Planeje uma etapa de reabertura em vez de presumir a recuperação.

Teste o comportamento com arquivos descartáveis antes de confiar nele. Um diretório que reaparece depois que o túnel retorna não prova que os handles anteriores ou o trabalho não salvo sobreviveram.