sshfs không tự động cài đặt khi khởi động, mặc dù cấu hình / etc / fstab


24

Thiết lập một số máy trạm Ubuntu (13.04), tôi đang cố gắng có một hệ thống tập tin từ xa được gắn (trên ssh).

Cấu hình hiện tại

  • Tôi đã tạo người dùng someuser và thêm nó vào cầu chì nhóm

  • Mục fstab của tôi đọc như sau:

    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
    

từ sự hiểu biết của tôi :

  • auto : rõ ràng là yêu cầu fs từ xa được gắn khi khởi động
  • _netdev : đợi giao diện được bật lên trước khi thử gắn kết
  • user : cho phép bất kỳ người dùng nào yêu cầu vị trí từ xa cụ thể này được gắn kết (vô dụng trong phối cảnh của người dùng root tự động gắn nó khi khởi động)
  • allow_other : sẽ cho phép bất kỳ người dùng nào (trong nhóm cầu chì?) truy cập vào fs được gắn kết
  • IdentityFile : trỏ đến khóa riêng được ghép nối với khóa chung được thêm vào /home/someuser/.ssh/authorized_key của máy từ xa.
  • kết nối lại : Không chắc chắn ... Sẽ cố gắng kết nối lại nếu kết nối bị mất?

Vấn đề

  • Khi khởi động, tôi đăng nhập với một số người dùng , kích hoạt thiết bị đầu cuối và / media / remote_dir trống.

  • Nhưng từ cùng một người dùng (hoặc root), tôi có thể gắn kết nó chỉ bằng cách gõ:

    mount sshfs#someuser@remote.com:/remote_dir
    

    Nó cũng được tự động gắn kết một cách kỳ diệu nếu tôi nhấp vào remote_dir trong trình duyệt tệp.

Bất kỳ manh mối liên quan đến những gì có thể thiếu?


Bao giờ có được điều này tìm ra? Tôi đang gặp vấn đề tương tự trên máy Ubuntu 14.04 64 bit.
glibdud

Thấy được sự phổ biến của câu hỏi này, so với số câu trả lời, tôi đã từ bỏ cách tiếp cận fstab. Tôi quyết định cắn viên đạn và học cách sử dụng Automount, giải quyết vấn đề bức tranh lớn. Theo kinh nghiệm của tôi, đó là "sự lựa chọn đúng đắn". Một giới thiệu tốt về Automount có thể được tìm thấy trên wiki Ubuntu .
Quảng cáo N

Câu trả lời:


18

Tôi đã trải nghiệm chính xác vấn đề tương tự sau khi nâng cấp từ Oneiric (nơi thiết bị tự động hoạt động tốt) lên Chính xác.

Điều giải quyết vấn đề cho tôi là thêm tùy chọn delay_connect . Ngoài ra, tôi đã sử dụng tùy chọn "workaround = đổi tên" trước đây, kể từ thời Oneiric. Không chắc ngày hôm nay có còn cần thiết hay không, nhưng ít nhất nó dường như không bị tổn thương.

Dòng đầy đủ / etc / fstab của tôi là:

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

Bạn rõ ràng sẽ cần phải điều chỉnh ID người dùng / nhóm với môi trường của riêng bạn.


1
Làm việc cho tôi mà không có cách giải quyết = đổi tên nơi nó không hoạt động trước đây. Vì vậy, thay đổi duy nhất của tôi là thêm tùy chọn delay_connect, điều đó chắc chắn đã giúp ở đây! Cảm ơn vì điều này. Chỉ tự hỏi tại sao _netdev không đủ ở đây ...
Nicolas

1
Điều đó cũng làm việc hoàn hảo cho tôi. @Nicolas, tôi tin rằng _netdevvấn đề được giải thích trong câu trả lời của Tony. Mạng có thể lên, nhưng nó vẫn không thể giải quyết máy chủ. Rõ ràng, sử dụng một địa chỉ IP sẽ giải quyết điều đó, nhưng ai muốn địa chỉ IP trong fstab của họ?
Auspex

Đối với những gì nó có giá trị, bằng cách nào đó khi tôi sao chép nó thành nguyên tử, nó đã nhặt được những nhân vật vô hình đã phá vỡ nó. Tôi phải xóa chúng
Jonathan

4
Nó gắn kết ổn nhưng sau đó tôi nhận được: ls / backup: Lỗi đầu vào / đầu ra
Jonathan

Thêm 'delay_connect, workaround = đổi tên' đã hoạt động với tôi trên Arch Linux. Cảm ơn!
aSystemOverload

1

Ngoài ra để bổ sung cho tất cả các ý kiến ​​trước đó,

  1. Đảm bảo rằng bạn cho phép người dùng không root xác định allow_othertùy chọn gắn kết trong/etc/fuse.conf

  2. Hãy chắc chắn rằng bạn sử dụng mỗi sshfs mount ít nhất một lần theo cách thủ công trong khi root để chữ ký của máy chủ được thêm vào ~/.ssh/known_hoststệp.

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

Tùy chọn mount allow_other cho thấy lỗi bảo mật chưa được giải quyết trong nhân Linux: nếu tùy chọn mount default_permissions KHÔNG được sử dụng cùng với allow_other, kết quả kiểm tra quyền đầu tiên được thực hiện bởi hệ thống tệp cho mục nhập thư mục sẽ được sử dụng lại cho các lần truy cập tiếp theo miễn là inode của mục nhập được truy cập có trong bộ đệm kernel - ngay cả khi các quyền đã thay đổi và ngay cả khi lần truy cập tiếp theo được thực hiện bởi một người dùng khác.
MountainX cho Monica Cellio

0

có cùng một vấn đề, tôi nghĩ bạn cần tự động là noauto. Nó không nên gắn kết khi khởi động, nó nên gắn kết khi eth lên


6
Tôi nghĩ rằng "chỉ gắn kết khi mạng sẵn sàng" đã được yêu cầu sử dụng _netdevvà việc thay đổi bằng noautosẽ khiến nó không thể gắn kết khi khởi động (chỉ rõ ràng khi sử dụng lệnh gắn kết )
Ad N

0

Nếu bạn phải gắn kết nó từ máy chủ DNS có thẩm quyền /etc/fstabvà tên máy chủ của máy chủ SFTP từ xa của bạn được cung cấp bởi máy chủ DNS này, bạn chắc chắn sẽ không thể kết nối vì chưa thể giải quyết tên máy chủ. Máy chủ DNS phải chạy trong khi cố gắng gắn kết hoặc bạn phải tìm một phương pháp thay thế để lấy địa chỉ IP của máy chủ từ xa.

Nếu đây là trường hợp, bạn có thể chọn bất kỳ giải pháp nào sau đây:

  • Thêm delay_connecttùy chọn để nó sẽ cho phép trình tự khởi động tiếp tục và sau khi trình tự khởi động đã khởi động máy chủ DNS, nó sẽ kết nối.
  • Thêm tên máy chủ của máy chủ SFTP từ xa vào /etc/hoststệp cục bộ của bạn bằng địa chỉ IP thích hợp.
  • Sử dụng địa chỉ IP của máy chủ SFTP từ xa fstabthay vì tên máy chủ.

Bạn có thể mở rộng trên các delay_connecttùy chọn? Nó được thêm vào đâu? Chỉnh sửa câu hỏi của bạn để bao gồm một số thông tin thêm về nó.
AJefferiss

Bạn thêm nó vào danh sách tùy chọn fstab: sshfs # user @ host: / remote / mnt / local fuse delay_connect, uid = 1000, gid = 100, umask = 0, allow_other 0 0
Tony
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.