web-dev-qa-db-fra.com

sshfs ne se monte pas automatiquement au démarrage, malgré la configuration de / etc / fstab

En installant une station de travail Ubuntu (13.04), j'essaie de monter un système de fichiers distant (sur ssh).

La configuration actuelle

  • J'ai créé l'utilisateur someuser et l'ajouté au groupe Fuse

  • Mon entrée fstab se lit comme suit:

    sshfs#[email protected]:/remote_dir  /media/remote_dir/   Fuse    auto,_netdev,port=22,user,allow_other,noatime,follow_symlinks,IdentityFile=/home/someuser/.ssh/id_rsa,reconnect     0       0

de ma compréhension:

  • auto: demande explicitement que le fs distant soit monté au démarrage
  • _ netdev: attend que l'interface soit active avant de tenter le montage
  • tilisateur: permet à tout utilisateur de demander le montage de cet emplacement distant spécifique (inutile dans la perspective de l'utilisateur root le montant automatiquement au démarrage)
  • allow_other: autorisera n'importe quel utilisateur (du groupe Fuse?) à accéder au fs monté
  • IdentityFile: pointe vers la clé privée associée à la clé publique ajoutée dans /home/someuser/.ssh/registered_key de la machine distante.
  • reconnecter: Pas sûr ... Est-ce que vous tenterez de vous reconnecter si la connexion est perdue?

Le problème

  • Au démarrage, je me connecte avec , someuser , allume un terminal et /media/remote_dir est vide.

  • Mais à partir du même utilisateur (ou de la racine), je peux le monter en tapant simplement:

    mount sshfs#[email protected]:/remote_dir

    Il est également monté automatiquement si je clique sur remote_dir dans un navigateur de fichiers.

Quel indice sur ce qui pourrait être manquant?

mountfstabsshfs
23
Ad N

J'ai rencontré exactement le même problème après la mise à niveau de Oneiric (où le montage automatique fonctionnait correctement) vers Precise.

Ce qui a résolu le problème pour moi, c’est d’ajouter l’option delay_connect. De plus, j'utilise déjà l'option "solution de contournement = renommer" depuis l'époque onirique. Je ne sais pas si cela est encore nécessaire aujourd'hui, mais au moins, cela ne semble pas faire mal.

Ma ligne complète/etc/fstab est la suivante:

sshfs#user@Host:/remote/dir /local/dir Fuse delay_connect,idmap=user,uid=1000,gid=1000,umask=0,allow_other,_netdev,workaround=rename 0 0

Vous devez évidemment adapter les identifiants d’utilisateur/groupe à votre propre environnement.

17
lbo

Si vous devez le monter à partir du /etc/fstab d'un serveur DNS faisant autorité et si le nom d'hôte de votre serveur SFTP distant est fourni par ce serveur DNS, vous ne pourrez certainement pas vous connecter car le nom d'hôte ne peut pas encore être résolu. Soit le serveur DNS doit être en cours d'exécution lors de la tentative de montage, soit vous devez rechercher une autre méthode pour obtenir l'adresse IP de votre serveur distant.

Si tel est le cas, vous pouvez choisir l'une des solutions suivantes:

  • Ajoutez l’option delay_connect afin qu’elle permette à la séquence de démarrage de se poursuivre et, une fois la séquence de démarrage lancée, le serveur DNS auquel il se connecte.
  • Ajoutez le nom d'hôte de votre serveur SFTP distant à votre fichier /etc/hosts avec l'adresse IP appropriée.
  • Utilisez l'adresse IP de votre serveur SFTP distant dans fstabà la place du nom d'hôte.
0
Tony

a eu le même problème, je pense que vous avez besoin d'auto pour être noauto. il ne devrait pas monter au démarrage, il devrait monter quand l'eth est en place

0
Piet Bijl

Également pour compléter tous les commentaires précédents,

  1. Assurez-vous d'autoriser les utilisateurs non root à spécifier l'option de montage allow_other dans /etc/Fuse.conf

  2. Assurez-vous d'utiliser chaque montage sshfs au moins une fois manuellement en tant qu'utilisateur root afin que la signature de l'hôte soit ajoutée au fichier ~/.ssh/known_hosts.

    sshfs [user]@[Host]:[remote_path] [local_path] -o allow_other,IdentityFile=[path_to_id_rsa]
0
Martin Brousseau