S3FS挂载S3桶遇403权限拒绝问题求助

既然你的AWS CLI操作完全正常，说明IAM凭证和权限本身没问题，问题大概率出在s3fs的配置或者版本特性上，我给你几个针对性的排查步骤：

1. 检查凭证文件的权限 #

s3fs对凭证文件的权限要求很严格，如果~/.aws/credentials的权限过于开放（比如允许其他用户读取），会自动拒绝加载。执行以下命令修正权限：

chmod 600 ~/.aws/credentials

2. 手动指定凭证文件路径 #

有时候s3fs可能无法自动识别AWS CLI的凭证位置，挂载时显式指定路径试试：

s3fs mybucket s3 -o use_cache=/tmp -o mp_umask=002 -o multireq_max=5 -o dbglevel=info -f -o endpoint=us-east-2 -o curldbg -o credential_file=~/.aws/credentials

3. 添加路径式请求参数 #

老版本的s3fs（比如你用的1.86）对部分区域的虚拟主机式请求支持不好，添加use_path_request_style参数强制使用路径式请求：

s3fs mybucket s3 -o use_cache=/tmp -o mp_umask=002 -o multireq_max=5 -o dbglevel=info -f -o endpoint=us-east-2 -o curldbg -o use_path_request_style

4. 验证IAM策略的即时性与细节 #

虽然你已经给IAM用户授予了完全访问权限，但新账号的IAM策略可能存在短暂的同步延迟（不过CLI能正常用的话这个概率很低）。你可以再次确认策略中包含以下关键权限（挂载S3桶必须用到）：

• s3:ListBucket（用于列出桶内对象，挂载时必备）
• s3:GetObject
• s3:PutObject
• s3:DeleteObject

5. 升级s3fs版本 #

你当前使用的1.86版本是2020年的旧版本，存在不少已知的签名兼容性问题，尤其是和AWS签名版本4的适配。建议升级到最新稳定版（比如当前的1.90+），很多权限相关的bug在新版本中已经修复。

6. 开启更详细的调试日志 #

把dbglevel调到debug，获取更完整的请求和签名信息，对比AWS CLI的请求细节，能帮你定位是不是签名生成环节出了问题：

s3fs mybucket s3 -o use_cache=/tmp -o mp_umask=002 -o multireq_max=5 -o dbglevel=debug -f -o endpoint=us-east-2 -o curldbg

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