Docker绑定挂载sftpman挂载的FUSE目录时提示目录不存在

优先排查宿主机侧的挂载可见性问题 #

Docker 进程读取 bind 挂载的源路径时，是以 root 权限、在宿主机全局挂载命名空间下做路径校验的，和你普通终端用户的视角存在天然隔离，这是该类报错的最高发原因：

• 先在你执行sftpman挂载的同一个终端下，执行ls /mnt/sshfs/some_fuse_directory，确认你当前用户视角下目录确实可访问
• 执行mount | grep sshfs，核对FUSE挂载的真实挂载点路径，排除sftpman实际生成的挂载路径和你docker-compose里写的source路径存在拼写、层级偏差
• 重点核查：FUSE sshfs默认是用户级私有挂载，挂载时会绑定当前执行挂载用户的uid，root身份、甚至其他系统用户都默认看不到这个挂载点——哪怕你当前用户能正常ls看到内容，Docker用root权限做路径校验时，依然会判定路径不存在。

对应问题的修复操作 #

1. 调整FUSE挂载权限，让全局所有用户可见 #

首先打开宿主机的FUSE全局配置文件/etc/fuse.conf，把user_allow_other行前的注释符号去掉，保存退出，允许FUSE挂载对外开放访问权限。
然后重新初始化sftpman的配置，追加sshfs的全局访问参数：

sftpman setup --id "some_fuse_directory" --host "xx.xxx.x.xx" --user "root" \
--mount_point "/path/on/server/to/see" --auth_method=publickey --ssh_key "/home/user/.ssh/id_rsa" \
--extra_sshfs_opts "allow_other,default_permissions"

执行完卸载原有挂载，重新挂载：

sftpman umount some_fuse_directory && sftpman mount some_fuse_directory

完成后切换root身份执行ls /mnt/sshfs/some_fuse_directory，确认root视角下也能正常看到目录内容，再校验路径有效性。

2. 解决挂载命名空间隔离问题 #

如果你之前的FUSE挂载是在tmux/screen会话、用户级systemd服务的独立挂载命名空间下执行的，哪怕权限放开了，全局命名空间下的Docker进程依然感知不到这个挂载。
这种场景下可以在docker-compose配置中追加对应权限参数，让容器可以正常访问FUSE类挂载：

webapp:
  image: "python-3.7.9-buster"
  volumes:
    - type: bind
      source: /mnt/sshfs/some_fuse_directory
      target: /root/some_fuse_directory
  # 新增以下配置适配FUSE挂载的访问要求
  cap_add:
    - SYS_ADMIN
  devices:
    - /dev/fuse

长期稳定使用的话，更推荐把sftpman的挂载操作配置成系统级systemd服务，让它在全局挂载命名空间下随系统启动自动挂载，从根源上避免命名空间隔离的问题。 #

兜底校验步骤 #

如果调整完依然报错，可以做两个简单的排查排除低级问题：

• 把docker-compose里的source路径临时改成宿主机上已知存在的普通目录，比如/tmp，重新启动服务，验证compose本身的路径解析逻辑没有拼写、格式错误
• 确认执行docker-compose up的操作用户，不是权限被限制、无法读取/mnt目录的低权限用户

内容的提问来源于stack exchange，提问作者Santhosh