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 : зачекайте, коли буде запущений інтерфейс, перш ніж намагатися встановити
  • користувач : дозвольте будь-якому користувачеві попросити встановити це певне віддалене місце (марно з точки зору кореневого користувача, який автоматично встановлює його під час завантаження)
  • enable_other : дозволить будь-якому користувачеві (в групі запобіжників?) отримати доступ до змонтованих файлів
  • IdentityFile : вказує на приватний ключ, поєднаний із відкритим ключем, доданим у /home/someuser/.ssh/authorized_key віддаленої машини.
  • Повторне з'єднання : Не впевнений ... Буде спроба відновити з'єднання, якщо з'єднання втрачено?

Проблема

  • Під час завантаження я входжу з користувачем , запускаю термінал, і / media / remote_dir порожній.

  • Але від того самого користувача (або кореня) я можу встановити його просто набравши:

    mount sshfs#someuser@remote.com:/remote_dir
    

    Він також автоматично магічно встановлений, якщо натиснути на remote_dir у файловому браузері.

Будь-яка підказка щодо того, що може бути відсутнім?


Колись розібралися в цьому? Я зіткнувся з тією ж проблемою на 64-бітній машині Ubuntu 14.04.
glibdud

Бачачи популярність цього питання, порівняно з кількістю відповідей, я відмовився від підходу fstab. Я вирішив кусати кулю і навчився користуватися Automount, вирішуючи проблему з великою картиною. З мого досвіду це був "правильний вибір". Хороший вступ до Automount можна знайти на вікі Ubuntu .
Оголошення N

Відповіді:


18

Точно таку ж проблему я пережив після переходу з Oneiric (де автоматичний апарат працював чудово) до Precision.

Що вирішило проблему для мене, було додавання опції delay_connect . Крім того, я використовував параметр "обхід = перейменувати" вже раніше, ще з 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
Це чудово працює і для мене. @Nicolas, я вважаю, що _netdevце пояснено у відповіді Тоні. Можливо, мережа працює, але вона все ще не може вирішити хост. Очевидно, використання IP-адреси вирішило б це, але хто хоче IP-адреси у своєму fstab?
Auspex

Для чого це варто, якимось чином, коли я копіював це вставлене в атом, він підбирав невидимих ​​символів, які його зламали. Мені довелося видалити їх
Джонатан

4
Це нормально, але тоді я отримую: ls / резервне копіювання: помилка вводу / виводу
Jonathan

Додавання 'delay_connect, методологічне вирішення = перейменування' працювало для мене в Arch Linux. Спасибі!
aSystemOverload

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]
    

Опція кріплення enable_other виявляє невирішену помилку безпеки в ядрі Linux: якщо опція монтажу default_permissions НЕ використовується разом з enable_other, результати першої перевірки дозволу, виконаної файловою системою для запису в каталозі, будуть повторно використані для наступних доступу до тих пір, поки в кеші ядра присутня inode запису, що звертається, - навіть якщо дозволи з тих пір змінилися і навіть якщо наступний доступ здійснює інший користувач.
MountainX для Моніки Селліо

0

була така ж проблема, я думаю, вам потрібно авто, щоб бути noauto. він не повинен монтуватися на завантажувальному пристрої, він повинен монтуватися, коли eth працює


6
Я думаю, що "монтувати лише тоді, коли мережа готова" вже запитується _netdev, і якщо змінити noauto, вона не зможе встановити під час завантаження (лише явно при використанні команди mount )
Ad N

0

Якщо ви хочете встановити його з авторитетного DNS-сервера, /etc/fstabа ім'я хоста вашого віддаленого SFTP-сервера надається цим DNS-сервером, ви, звичайно, не зможете підключитися, оскільки ім'я хоста ще не вирішено. Або під час спроби встановити DNS-сервер повинен працювати, або потрібно знайти альтернативний спосіб отримання IP-адреси віддаленого сервера.

У такому випадку ви можете вибрати будь-яке з наступних рішень:

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

Чи можете ви розширити delay_connectопцію? Де додано? Відредагуйте своє запитання, щоб включити ще трохи інформації про нього.
AJefferiss

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