系统是 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 在代理转发过程中篡改了内容导致签名失败。
-
+1 求助
可以了,Regoin 我的改 oss 地域 ID 可以了 https://help.aliyun.com/zh/oss/user-guide/regions-and-endpoints?utm_source=ld246.commuweize • -
+1,我的是自家的 minio S3,地区我自己填的 zh_cn,之前只要服务器和客户端能对上就行,更新之后的提示和你的一样。
更新之前还测试过可以同步,更新后马上就失效了。
1 回复minio 和思源都改成 cn-beijing 之后还是有报错: operation error S3: ListBuckets, https response error StatusCode: 403, RequestID: 18155E8E4B17xxxx, HostID: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2xxxx, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method. (Provider: S3)Whacka • -
感谢,试了修改 minio 服务器 Region 为 us-east-1,思源里也同步修改,点击云端同步设置的按钮,依然这个错误:
- operation error S3: ListBuckets, https response error StatusCode: 403, RequestID: 18155F8868F8569E, HostID: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method. (Provider: S3)
1 回复 -
-
感谢回复。试了一下换成 virtual-hosted-style,还是不行。我又重新生成了一个 key,还是出现同样的错误。。。
operation error S3: ListBuckets, https response error StatusCode: 403, RequestID: 1815ED86DD66ED94, HostID: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method. (Provider: S3)
我感觉应该是 Secret key 没有被正确传进去,毕竟配置不变,降级成 3.1.16 就完全没问题
1 回复 -
找到一篇博文, 可能说明了为啥会签名失败:
https://blog.csdn.net/cucgyfjklx/article/details/133165964
大意是通过 Nginx 反代了 MinIO 的服务后会因为 ip 的变更导致前后端计算签名的参数(ip)不一致。
我不是很懂 Nginx 和相关技术,我使用的是 CF 的 Tunnel 方案,也许有类似的问题。
1 回复 -
-
使命感油然而生,然而我折腾了几天之后还是决定放弃了,我改用 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 在代理转发过程中篡改了内容导致签名失败。