系统是 MacOS M1,和之前的版本一样更新,未对 S3 配置做任何修改,并且其它设备 3.1.16 的版本同步正常,是阿里云的桶。不知道有人遇到一样的问题吗,有解决方案吗?谢谢 ~
相关帖子
-
使命感油然而生,然而我折腾了几天之后还是决定放弃了,我改用 CloudFlare R2 作为主要同步服务器,群晖上用 rclone 定期同步数据做备份。
我的环境:
服务器:群晖 Docker MinIO(还是 24 年中的版本,Docker Hub 被禁用之后我不会升级版本。。。),没有公网 ip 所以选择 CloudFlare Tunnel 做内网穿透。
客户端:MacBookPro Intel 版本,思源 3.1.18。
我的一些观察:
- 我 blame 了一下思源里 S3 获取 Buckets 列表相关的代码,这部分于 2 周前更新了亚马逊的 sdk v2 版本。在亚马逊的 github 里看到 ListBuckets 函数调用了 c 的函数,具体的签名过程我不知道从哪里查看。
- 在 CloudFlare Tunnel 的监听界面里可以获取到访问记录的 http url 和 headers,我对比了 3.1.17 和 3.1.16(iOS)点击“设置”时访问的获取 Buckets 列表操作的记录,发现 url 有比较大的不同,3.1.17 的 url 是
GET https://minioapi.example.com/?x-id=ListBuckets HTTP/1.1
,而 3.1.16 则是GET https://minioapi.example.com/ HTTP/1.1
;headers 内容略有不同,但其中非常关键的信息是X-Amz-Date
(例如20241231T133058Z
),这是一个 UTC 时间精确到秒,在相关文档里明确说了这条目是签名认证的关键信息,我用 CloudFlare Rules 调整了一下这个时间果然得到了明确的新的错误信息(格式不正确,或者时间相差太多),但这个条目与我遇到的问题应该没啥关系,因为两个版本发送的 header 里都有它。另一个关键的 header 就是X-Forwarded-For
,然而 CloudFlare Rules 里不允许修改这条的内容,因此我无法确认是否因为 CloudFlare 在代理转发过程中篡改了内容导致签名失败。
-
- 其他回帖
- 查看全部回帖