Назад | Перейти на главную страницу

SSHFS: конечная точка транспорта не подключена

На сайтах Stack Exchange есть несколько сообщений, касающихся проблемы, указанной в заголовке, но, похоже, ни одна из них не предлагает такого отличного решения. Этот пост, я полагаю, является бесстыдной попыткой решить эту проблему (некоторым из них уже несколько лет) и посмотреть, есть ли у кого-нибудь хорошее решение для этого - я думаю, может быть, проверенная комбинация опций, предоставляемых autofs, в отличие от некоторого обходного пути / сценария мониторинга.

Я только что поднял этот как проблема с SSHFS, но, по-видимому, нет текущих сопровождающих ...

Чтобы повторить содержание отчета об ошибке, поскольку я знаю, что люди предпочитают не полагаться на возможно эфемерные внешние ссылки:

--------- НАЧАТЬ ПАСТА ---------

Я подозреваю, что эта проблема известна / понятна, но я не могу найти по ней открытой проблемы.

Это было проблемой для меня в течение некоторого времени, и погоня за потоками в Stack Overflow и т.п. (поиск sshfs «Транспортная конечная точка не подключена») подсказывает мне, что это проблема давней давности, которая никогда не решалась. Будет ли исправление в sshfs или где-либо еще, я не знаю, но я думаю, что вполне разумно ожидать, что будет предпринята попытка повторного подключения, если параметр повторного подключения был передан, а точка монтирования больше не доступна.

Проблема возникает, когда крепление все еще отображается в mount, но для этого нет процесса в sshfs, например:

Обратите внимание, что хотя я изменил некоторых пользователей / пути для анонимности, в остальном проблема точно такая же, как описано, то есть обе точки монтирования, одна из которых в настоящее время работает, а другая нет, находятся рядом как на сервере, так и на клиенте (так что вы можете ожидать их либо работать, либо терпеть неудачу вместе, но они этого не делают).

Конфигурация Autofs:

cat /etc/auto.sshfs
data1 -fstype=fuse,port=22,rw,nodev,nonempty,noatime,allow_other,max_read=65536,reconnect,workaround=all,ServerAliveInterval=15,ServerAliveCountMax=3 :sshfs\#user@server1\:/storage/data1
data2 -fstype=fuse,port=22,rw,nodev,nonempty,noatime,allow_other,max_read=65536,reconnect,workaround=all,ServerAliveInterval=15,ServerAliveCountMax=3 :sshfs\#user@server1\:/storage/data2

Вывод команды монтирования:

mount | grep server1
user@server1:/storage/data1 on /mnt/sshfs/data1 type fuse.sshfs (rw,nodev,noatime,user_id=0,group_id=0,allow_other)
user@server1:/storage/data2 on /mnt/sshfs/data2 type fuse.sshfs (rw,nodev,noatime,user_id=0,group_id=0,allow_other)

Статус autofs (обратите внимание на отсутствие точки монтирования data2, указанной выше):

user@serverx:/home/user# systemctl status autofs
● autofs.service - Automounts filesystems on demand
Loaded: loaded (/lib/systemd/system/autofs.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-10-23 14:46:52 UTC; 2 months 13 days ago
Main PID: 8524 (automount)
Tasks: 17 (limit: 4915)
Memory: 8.8M
CPU: 18h 19min 6.124s
CGroup: /system.slice/autofs.service
├─8524 /usr/sbin/automount --pid-file /var/run/autofs.pid
├─8718 ssh -X -a -oClearAllForwardings=yes -oport=22 -oServerAliveInterval=15 -oServerAliveCountMax=3 -2 user@server1 -s sftp
└─8755 sshfs user@server1:/storage/data1 /mnt/sshfs/data1 -o rw,nodev,noatime,uid=0,gid=0,port=22,nonempty,allow_other,max_read=65536,reconnect,workaround=[truncated by terminal]

Теперь, если я umount / mnt / sshfs / data2, затем попробуйте ls того же каталога том автоматически перемонтируется. Но без umount, ls (здесь родительского каталога) дает:

user@serverx:/home/user# ls -l /mnt/sshfs/
ls: cannot access '/mnt/sshfs/data2': Transport endpoint is not connected
total 4
drwxr-xr-x 1 root root 4096 Jul 22 11:46 data1
d????????? ? ? ? ? ? data2

Итак, почему том не перемонтируется автоматически, когда попытки доступа к нему возвращают ошибку «не подключен»?

--------- КОНЕЦ ПАСТА ---------

РЕДАКТИРОВАТЬ:

Мне кажется, что я без нужды создаю здесь два соединения, хотя на самом деле я мог бы просто смонтировать родительский каталог / хранилище /. Но насколько я могу судить, это не причиняет никакого вреда (на самом деле я только что смонтировал третий каталог, и все они работают нормально). В любом случае, будет ли какое-то преимущество, если весь трафик будет проходить через одну родительскую точку монтирования? Есть ли вероятность конфликта между двумя (или более) процессами ssh (они идентичны в командной строке: ssh -X -a -oClearAllForwardings = yes -oport = 22 -oServerAliveInterval = 15 -oServerAliveCountMax = 3-2 user @ server1 - s sftp)?

РЕДАКТИРОВАТЬ:

Я только что немного поэкспериментировал, убивая различные элементы на клиенте / сервере, и единственный способ воспроизвести проблему, с которой я иногда сталкиваюсь, - это убить sshfs на клиенте:

Убить сеанс ssh на сервере: монтирование восстанавливается

Убить sftp-server на сервере: mount recovers

убить сеанс ssh на клиенте: монтировать восстанавливает

убить sshfs на клиенте: нужно вручную umount, после чего он снова монтируется по требованию (как изначально описывалась проблема)

Итак, без конкретных доказательств я предполагаю, что сам sshfs иногда завершает работу. Должен ли autofs справиться с этим?