sshfs tidak dipasang secara otomatis saat boot, meskipun ada konfigurasi / etc / fstab


24

Menyiapkan beberapa workstation Ubuntu (13.04), saya mencoba memasang sistem file jarak jauh (over ssh).

Konfigurasi saat ini

  • Saya dibuat pengguna someuser dan ditambahkan ke sekering kelompok

  • Entri fstab saya berbunyi seperti:

    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
    

dari pengertian saya:

  • auto : secara eksplisit meminta remote fs untuk dipasang saat boot
  • _netdev : tunggu hingga antarmuka naik sebelum mencoba melakukan mount
  • pengguna : izinkan pengguna mana pun untuk meminta lokasi jarak jauh khusus ini untuk dipasang (tidak berguna dalam perspektif pengguna root secara otomatis memasangnya saat boot)
  • allow_other : akan mengizinkan pengguna mana pun (dalam grup sekering?) untuk mengakses fs yang dipasang
  • IdentityFile : menunjuk ke kunci pribadi yang dipasangkan dengan kunci publik yang ditambahkan di /home/someuser/.ssh/authorized_key dari mesin jarak jauh.
  • menghubungkan kembali : Tidak yakin ... Akankah mencoba untuk menyambung kembali jika koneksi terputus?

Masalah

  • Saat boot, saya log dengan someuser , jalankan terminal, dan / media / remote_dir kosong.

  • Tapi dari pengguna yang sama (atau root), saya bisa memasangnya hanya mengetik:

    mount sshfs#someuser@remote.com:/remote_dir
    

    Itu juga secara otomatis dipasang jika saya mengklik remote_dir di peramban file.

Adakah petunjuk tentang apa yang bisa hilang?


Pernah tahu ini? Saya mengalami masalah yang sama pada mesin Ubuntu 14.04 64-bit.
glibdud

Melihat popularitas pertanyaan ini, dibandingkan dengan jumlah jawaban, saya menyerah pada pendekatan fstab. Saya memutuskan untuk menggigit peluru dan belajar cara menggunakan Automount, mengatasi masalah gambaran besar. Dari pengalaman saya itu adalah "pilihan yang tepat". Pengantar Automount yang baik dapat ditemukan di wiki Ubuntu .
Iklan N

Jawaban:


18

Saya mengalami masalah yang sama persis setelah memutakhirkan dari Oneiric (di mana automount bekerja dengan baik) menjadi Precise.

Apa yang memecahkan masalah bagi saya adalah menambahkan opsi delay_connect . Selain itu, saya sudah menggunakan opsi "workaround = rename" sudah sebelumnya, sejak Oneiric kali. Tidak yakin apakah masih diperlukan hari ini, tapi setidaknya sepertinya tidak sakit.

Baris penuh saya / etc / fstab adalah:

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

Anda jelas perlu menyesuaikan ID pengguna / grup dengan lingkungan Anda sendiri.


1
Bekerja untuk saya tanpa penyelesaian = ganti nama tempat yang tidak berhasil sebelumnya. Jadi satu-satunya perubahan saya adalah menambahkan opsi delay_connect, yang pasti membantu di sini! Terima kasih untuk ini. Hanya bertanya-tanya mengapa _netdev tidak cukup di sini ...
Nicolas

1
Itu juga cocok untuk saya. @ Nicolas, saya percaya _netdevmasalah ini dijelaskan dalam jawaban Tony. Jaringan mungkin aktif, tetapi masih tidak dapat menyelesaikan host. Jelas, menggunakan alamat IP akan menyelesaikannya, tetapi siapa yang mau alamat IP di fstab mereka?
Auspex

Untuk apa nilainya, entah bagaimana ketika saya salin menempelkan ini ke dalam atom, itu mengambil karakter yang tidak terlihat yang memecahkannya. Saya harus menghapusnya
Jonathan

4
Mount baik-baik saja tapi kemudian saya mendapatkan: ls / backup: Kesalahan input / output
Jonathan

Menambahkan 'delay_connect, workaround = rename' bekerja untuk saya di Arch Linux. Terima kasih!
aSystemOverload

1

Juga untuk melengkapi semua komentar sebelumnya,

  1. Pastikan Anda mengizinkan pengguna non-root untuk menentukan allow_otheropsi pemasangan di/etc/fuse.conf

  2. Pastikan Anda menggunakan setiap sshfs mount setidaknya sekali secara manual saat melakukan root sehingga tanda tangan host ditambahkan ke ~/.ssh/known_hostsfile.

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

Opsi mount allow_other memperlihatkan bug keamanan yang tidak terselesaikan di kernel Linux: jika opsi mount default_permissions TIDAK digunakan bersama dengan allow_other, hasil pemeriksaan izin pertama yang dilakukan oleh sistem file untuk entri direktori akan digunakan kembali untuk akses selanjutnya selama inode dari entri yang diakses ada di cache kernel - bahkan jika izin telah berubah, dan bahkan jika akses selanjutnya dilakukan oleh pengguna yang berbeda.
MountainX untuk Monica Cellio

0

punya masalah yang sama, saya pikir Anda perlu otomatis menjadi noauto. itu tidak boleh me-mount saat boot, itu harus me-mount ketika et up


6
Saya pikir "mount hanya ketika jaringan siap" sudah diminta menggunakan _netdev, dan mengubah dengan noautoakan membuatnya tidak dapat me-mount saat boot (hanya secara eksplisit ketika menggunakan perintah mount )
Ad N

0

Jika Anda ingin memasangnya dari server DNS yang berwenang /etc/fstabdan nama host dari server SFTP jarak jauh Anda disediakan oleh server DNS ini, Anda tentu tidak akan dapat terhubung karena nama host belum dapat diselesaikan. Server DNS harus dijalankan saat mencoba melakukan mount atau Anda harus menemukan metode alternatif untuk mendapatkan alamat IP server jarak jauh Anda.

Jika ini masalahnya, Anda dapat memilih salah satu dari solusi berikut:

  • Tambahkan delay_connectopsi sehingga akan memungkinkan urutan boot untuk melanjutkan dan setelah urutan boot memulai server DNS itu akan terhubung.
  • Tambahkan nama host server SFTP jarak jauh Anda ke /etc/hostsfile lokal Anda dengan alamat IP yang sesuai.
  • Gunakan alamat IP server SFTP jarak jauh Anda sebagai fstabganti nama host.

Bisakah Anda memperluas delay_connectopsi? Di mana itu ditambahkan? Edit pertanyaan Anda untuk memasukkan beberapa informasi lebih lanjut tentang itu.
AJefferiss

Anda menambahkannya dalam daftar opsi fstab: sshfs # user @ host: / remote / mnt / local fuse delay_connect, uid = 1000, gid = 100, umask = 0, allow_other 0 0
Tony
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.