sshfs не монтируется автоматически при загрузке, несмотря на конфигурацию / etc / fstab


24

Устанавливая какую-то рабочую станцию ​​Ubuntu (13.04), я пытаюсь смонтировать удаленную файловую систему (через ssh).

Текущий конфиг

  • Я создал пользовательский someuser и добавил его в предохранителе группу

  • Моя запись в fstab выглядит так:

    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
    

из моего понимания:

  • auto : явно запрашивает монтирование удаленного fs при загрузке
  • _netdev : дождитесь подключения интерфейса, прежде чем пытаться подключить
  • user : разрешить любому пользователю запрашивать монтирование этого удаленного местоположения (бесполезно с точки зрения пользователя root, автоматически монтирующего его при загрузке)
  • allow_other : позволит любому пользователю (в группе предохранителей?) получить доступ к смонтированному файлу
  • IdentityFile : указывает на закрытый ключ в паре с открытым ключом, добавленным в /home/someuser/.ssh/authorized_key удаленного компьютера.
  • Переподключение : Не уверен ... Попытаетесь восстановить соединение, если соединение потеряно?

Проблема

  • При загрузке я регистрируюсь с someuser , запускаю терминал, и / media / remote_dir пуст.

  • Но от того же пользователя (или рута) я могу смонтировать его, набрав:

    mount sshfs#someuser@remote.com:/remote_dir
    

    Он также автоматически монтируется, если я нажимаю на remote_dir в файловом браузере.

Любая подсказка относительно того, что может отсутствовать?


Вы когда-нибудь поняли это? Я столкнулся с той же проблемой на 64-битной машине с Ubuntu 14.04.
glibdud

Видя популярность этого вопроса, по сравнению с количеством ответов, я отказался от подхода fstab. Я решил укусить пулю и научиться использовать Automount, решая проблему с общей картиной. По моему опыту это был «правильный выбор». Хорошее введение в Automount можно найти в вики Ubuntu .
Объявление N

Ответы:


18

У меня возникла та же проблема после обновления с Oneiric (где автомонтирование работало нормально) до Precise.

Что решило проблему для меня, так это добавление опции delay_connect . Кроме того, я уже использовал опцию "workaround = rename", еще с времен Oneiric. Не уверен, что это все еще нужно сегодня, но, по крайней мере, это не больно.

Моя полная строка / etc / fstab:

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

Вам, очевидно, нужно будет адаптировать идентификаторы пользователей / групп к вашей собственной среде.


1
Работал для меня без обходного пути = переименовать, где он не работал раньше. Поэтому мое единственное изменение - добавление опции delay_connect, которая определенно помогла здесь! Спасибо тебе за это. Просто интересно, почему _netdev здесь недостаточно ...
Николас

1
Это прекрасно работает и для меня. @ Николас, я думаю, что _netdevпроблема объясняется в ответе Тони. Возможно, сеть подключена, но не может разрешить хост. Очевидно, что использование IP-адреса решило бы это, но кому нужны IP-адреса в их fstab?
Auspex

Что бы это ни стоило, каким-то образом, когда я копировал, вставил это в атом, он подобрал невидимые символы, которые сломали его. Я должен был удалить те
Джонатан

4
Он монтируется хорошо, но затем я получаю: ls / backup: Ошибка ввода / вывода
Jonathan

Добавление 'delay_connect, workaround = rename' работало для меня в Arch Linux. Благодарность!
Перегрузка системы

1

Также, чтобы дополнить все предыдущие комментарии,

  1. Убедитесь, что вы разрешаете некорневым пользователям указывать allow_otherопцию монтирования в/etc/fuse.conf

  2. Убедитесь, что вы используете каждое монтирование sshfs хотя бы один раз вручную в режиме root, чтобы в ~/.ssh/known_hostsфайл была добавлена ​​подпись хоста .

    sshfs [user]@[host]:[remote_path] [local_path] -o allow_other,IdentityFile=[path_to_id_rsa]
    

Параметр allow_other mount выявляет неразрешенную ошибку безопасности в ядре Linux: если опция монтирования default_permissions НЕ используется вместе с allow_other, результаты первой проверки прав доступа, выполненной файловой системой для записи каталога, будут повторно использованы для последующих обращений до тех пор, пока инод доступной записи присутствует в кэше ядра - даже если с тех пор разрешения изменились, и даже если последующий доступ сделан другим пользователем.
MountainX для Моники Челлио

0

была та же проблема, я думаю, вам нужно авто, чтобы быть noauto. он не должен монтироваться при загрузке, он должен монтироваться при включенном eth


6
Я думаю, что «монтировать только тогда, когда сеть готова» уже запрашивается с помощью _netdev, а изменение с помощью noautoсделает его не способным монтировать при загрузке (только явно при использовании команды монтирования )
Объявление N

0

Если вам необходимо смонтировать его с авторитетного DNS-сервера, /etc/fstabи имя DNS-сервера вашего удаленного SFTP-сервера предоставляется этим DNS-сервером, вы, безусловно, не сможете подключиться, поскольку имя хоста еще не может быть разрешено. Либо DNS-сервер должен быть запущен при попытке монтирования, либо вы должны найти альтернативный способ получения IP-адреса вашего удаленного сервера.

Если это так, вы можете выбрать любое из следующих решений:

  • Добавьте эту delay_connectопцию, чтобы позволить последовательности загрузки продолжаться, и после запуска последовательности загрузки DNS-сервер подключится.
  • Добавьте имя хоста вашего удаленного SFTP-сервера в локальный /etc/hostsфайл с соответствующим IP-адресом.
  • fstabВместо имени хоста используйте IP-адрес вашего удаленного SFTP-сервера .

Можете ли вы расширить delay_connectвыбор? Где это добавлено? Отредактируйте свой вопрос, чтобы включить в него дополнительную информацию.
AJefferiss

Вы добавляете его в список опций fstab: sshfs # user @ host: / remote / mnt / local fuse delay_connect, uid = 1000, gid = 100, umask = 0, allow_other 0 0
Tony
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.