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

24

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

La configuration actuelle

J'ai créé l'utilisateur someuser et l' ai ajouté au groupe de fusibles

Mon entrée fstab se lit comme suit:

sshfs#someuser@remote.com:/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 les fs distants soient montés au démarrage
_netdev : attendez que l'interface soit active avant de tenter de monter
utilisateur : permet à tout utilisateur de demander le montage de cet emplacement distant spécifique (inutile du point de vue de l'utilisateur root qui le monte automatiquement au démarrage)
allow_other : permettra à tout utilisateur (dans le groupe de fusibles?) d'accéder aux fs montés
IdentityFile : pointe vers la clé privée associée à la clé publique ajoutée dans /home/someuser/.ssh/authorized_key de la machine distante.
reconnecter : pas sûr ... va tenter de se reconnecter si la connexion est perdue?

Le problème

Au démarrage, je me connecte avec someuser , lance 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#someuser@remote.com:/remote_dir
```
Il est également monté automatiquement par magie si je clique sur remote_dir dans un navigateur de fichiers.

Un indice sur ce qui pourrait manquer?

mount fstab sshfs

— Annonce N
source

Avez-vous déjà compris cela? Je rencontre le même problème sur une machine Ubuntu 14.04 64 bits.

— glibdud

Voyant la popularité de cette question, par rapport au nombre de réponses, j'ai abandonné l'approche fstab. J'ai décidé de mordre la balle et d'apprendre à utiliser Automount, en résolvant le problème d'ensemble. D'après mon expérience, c'était "le bon choix". Une bonne introduction à Automount peut être trouvée sur le wiki Ubuntu .

— Annonce N

18

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

Ce qui a résolu le problème pour moi, c'était l'ajout de l' option delay_connect . De plus, j'utilisais déjà l'option "workaround = rename" depuis l'époque Oneiric. Je ne sais pas si c'est encore nécessaire aujourd'hui, mais au moins cela ne semble pas faire de mal.

Ma ligne complète / etc / fstab est:

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 devrez évidemment adapter les ID utilisateur / groupe à votre propre environnement.

— lbo
source

1

A fonctionné pour moi sans solution de contournement = renommer là où cela ne fonctionnait pas auparavant. Donc, mon seul changement a été d'ajouter l'option delay_connect, qui a certainement aidé ici! Merci pour ça. Je me demande juste pourquoi _netdev ne suffit pas ici ...

— Nicolas

1

Cela fonctionne parfaitement pour moi aussi. @Nicolas, je crois que le _netdevproblème est expliqué dans la réponse de Tony. Le réseau est peut-être en place, mais il ne peut toujours pas résoudre l'hôte. Évidemment, l'utilisation d'une adresse IP résoudrait cela, mais qui veut des adresses IP dans leur fstab?

— Auspex du

Pour ce que ça vaut, d'une manière ou d'une autre quand j'ai copié cela dans l'atome, il a détecté des caractères invisibles qui l'ont cassé. J'ai dû les retirer

— Jonathan

4

Il se monte bien mais j'obtiens: ls / backup: erreur d'entrée / sortie

— Jonathan

L'ajout de 'delay_connect, workaround = rename' a fonctionné pour moi sur Arch Linux. Merci!

— aSystemOverload

1

Pour compléter également tous les commentaires précédents,

Assurez-vous d'autoriser les utilisateurs non root à spécifier l' allow_otheroption de montage dans/etc/fuse.conf
Assurez-vous d'utiliser chaque montage sshfs au moins une fois manuellement en tant que root pour que la signature de l'hôte soit ajoutée au ~/.ssh/known_hostsfichier.
```
sshfs [user]@[host]:[remote_path] [local_path] -o allow_other,IdentityFile=[path_to_id_rsa]
```

— Martin Brousseau
source

L'option de montage allow_other expose un bogue de sécurité non résolu dans le noyau Linux: si l'option de montage default_permissions n'est PAS utilisée avec allow_other, les résultats de la première vérification des autorisations effectuée par le système de fichiers pour une entrée de répertoire seront réutilisés pour les accès ultérieurs tant que l'inode de l'entrée accédée est présent dans le cache du noyau - même si les autorisations ont depuis changé, et même si l'accès suivant est effectué par un autre utilisateur.

— MountainX pour Monica Cellio le

0

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'éth est en place

— Piet Bijl
source

6

Je pense que le "montage uniquement lorsque le réseau est prêt" est déjà demandé à l'aide _netdev, et le changement avec noautole rendrait impossible de monter au démarrage (uniquement explicitement lors de l'utilisation de la commande mount )

— Annonce N

0

Si vous devez le monter à partir d'un serveur DNS faisant autorité /etc/fstabet que 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 trouver 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' delay_connectoption pour permettre à la séquence de démarrage de continuer et après le démarrage de la séquence de démarrage, le serveur DNS se connectera.
Ajoutez le nom d'hôte de votre serveur SFTP distant à votre /etc/hostsfichier local avec l'adresse IP appropriée.
Utilisez l'adresse IP de votre serveur SFTP distant au fstablieu du nom d'hôte.

— Tony
source

Pouvez-vous développer cette delay_connectoption? Où est-il ajouté? Modifiez votre question pour inclure plus d'informations à ce sujet.

— AJefferiss

Vous l'ajoutez dans la liste d'options fstab: sshfs # user @ host: / remote / mnt / local fuse delay_connect, uid = 1000, gid = 100, umask = 0, allow_other 0 0

— Tony