使用goofys挂载S3桶后，root用户无法从顶层目录访问子目录的问题

我通过以下命令挂载了AWS S3桶：

sudo goofys -o allow_other mybucket /mnt/buckets/mybucket/

该桶内包含多个子目录。当我使用sudo执行rsync或cp命令复制部分子目录时，遇到了如下问题：

sudo cp -rv /mnt/buckets/mybucket/a /destination
cp: cannot access '/mnt/buckets/mybucket/a/b/c': Input/output error

sudo rsync -arv --delete /mnt/buckets/mybucket/a /destination
rsync: [sender] readdir("/mnt/buckets/mybucket/a/b/c"): Input/output error (5)
IO error encountered -- skipping file deletion

但如果直接复制完整路径，例如执行sudo cp -rv /mnt/buckets/mybucket/a/b/c /destination则完全正常。

我执行ls -al检查权限，所有目录及子目录均对root和其他用户开放全权限。

首次执行ls -al /mnt/buckets/mybucket/a/b/c时出现如下错误：

ls: reading directory '/mnt/buckets/mybucket/a/b/c': Input/output error

但多次执行该命令后，最终可以正常查看该目录下的所有文件及子目录。

请问这是什么原因导致的？

核心原因：Goofys的延迟加载与元数据缓存特性 #

Goofys是基于FUSE的S3挂载工具，它采用延迟加载机制获取S3对象元数据——只有当实际访问目录时，才会向S3 API发起请求拉取对应前缀的对象列表。由于S3是对象存储，没有真实目录结构，Goofys需要通过列举前缀模拟目录，这个过程依赖网络请求，一旦网络波动或S3 API响应延迟，就会触发IO错误。

你遇到的现象完全匹配这个机制：

• 首次访问目标目录时，Goofys实时从S3拉取元数据，若请求超时或失败就抛出IO错误；
• 多次执行后，Goofys缓存了已获取的元数据，后续访问即可正常返回；
• 直接复制完整路径时，无需递归列举上层目录元数据，仅处理单个路径对象，因此不会触发目录列举的IO错误。

另外，sudo执行命令时，FUSE的allow_other参数虽允许非挂载用户访问，但root用户的环境变量、FUSE缓存上下文与普通用户存在差异，可能加剧元数据加载的不稳定。

解决办法 #

• 预加载目录元数据
  执行复制命令前，先递归遍历目标目录触发Goofys元数据缓存：

  sudo find /mnt/buckets/mybucket/a -type d > /dev/null
  

  该命令会遍历所有子目录，让Goofys提前拉取并缓存元数据，后续cp或rsync操作即可避免IO错误。

• 调整Goofys挂载参数
  添加缓存相关参数延长元数据缓存时间，减少重复请求：

  sudo goofys -o allow_other -o stat-cache-ttl=3600 -o dir-cache-ttl=3600 mybucket /mnt/buckets/mybucket/
  

  • stat-cache-ttl：设置文件/目录元数据缓存时长（单位：秒），默认1秒；
  • dir-cache-ttl：设置目录列表缓存时长（单位：秒），默认1秒。
    延长缓存时间可降低S3 API请求频次，减少IO错误概率。

• 替换为更稳定的工具
  若Goofys稳定性无法满足需求，可选择以下方案：

  • 使用s3fs：同样是FUSE挂载工具，元数据缓存机制更成熟，稳定性优于Goofys；
  • 直接用AWS CLI同步：执行aws s3 sync s3://mybucket/a /destination，绕过FUSE挂载层，直接通过AWS API完成同步，避免挂载相关问题。

• 排查网络与权限
  确保服务器到S3的网络连接稳定，无防火墙或安全组限制S3 API访问；同时确认挂载所用IAM角色/用户拥有s3:ListBucket权限（虽多次执行后能成功，权限问题概率较低，但仍需排查）。

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