### Author:  [@dino](https://meta.discourse.org/u/dino)
#### Post date: [2020年二月4日 15:54 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/1 "2020-02-04T15:54:52Z")
您好，
我正在尝试配置 Discourse 以使用 Scaleway 的 S3 兼容对象存储，但似乎无法使其正常工作，且不确定问题出在哪里。
我已通过 aws-cli 验证了两个存储桶均可正常使用，并参照 Scaleway 官方文档正确配置了 CORS 设置，因此我认为问题不在存储桶本身。
以下是我的 Discourse S3 设置（部分存储桶名称已隐藏）：
当我打开备份标签页时，会收到错误提示：“Failed to list backups from S3: Aws::S3::Errors::BadRequest”。
而当我尝试上传图片时，日志中显示：“Job exception: Failed to open TCP connection to [redacted]-discourse-files.s3.fr-par.**[amazonaws.com](http://amazonaws.com)**:443 (getaddrinfo: Name or service not known)”。
我运行的是最新版本的 Discourse - 2.4.0.beta10 (14ae574bc5)。
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2020年二月4日 16:13 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/2 "2020-02-04T16:13:11Z")
我猜他们的 S3 兼容性可能不如他们自己认为的那么高？
S3 区域设置似乎也在影响这里的情况。
---
### Author:  [@dino](https://meta.discourse.org/u/dino)
#### Post date: [2020年二月4日 16:40 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/3 "2020-02-04T16:40:50Z")
这是可能的，但如果我输入了端点，URL 就不应该包含 [amazonaws.com](http://amazonaws.com)，对吧？
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2020年二月4日 16:52 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/4 "2020-02-04T16:52:10Z")
没错，这很奇怪。可能是因为那个标新立异的顶级域名？让我看看。
@dino 试着从 `s3 endpoint` 中移除 `https://`
---
### Author:  [@dino](https://meta.discourse.org/u/dino)
#### Post date: [2020年二月4日 19:23 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/5 "2020-02-04T19:23:17Z")
验证不允许我执行该操作：‘s3\_endpoint：值不符合所需格式。’
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2020年二月4日 20:59 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/6 "2020-02-04T20:59:49Z")
是的，那是一个错误的猜测。
我无法通过阅读相关代码找到以与你相同的 URL 结尾的方法：
>
这是否只影响备份？上传功能是否正常？
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2020年二月4日 21:06 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/7 "2020-02-04T21:06:18Z")
> [@dino](#):
>
> 当我打开备份标签页时，出现“从 S3 列出备份失败：Aws::S3::Errors::BadRequest”错误。
嗯，这和我之前遇到的 GCP 存储桶问题不太一样，不过你可以看看这个链接：[Trouble with Google Bucket for backup - #4 by pfaffman](https://meta.discourse.org/t/trouble-with-google-bucket-for-backup/139959/4?u=pfaffman%E3%80%82)
我后来查出了是哪个 `aws-sdk-s3` gem 的升级导致 GCP 存储桶无法使用，不过我的客户最终选择切换到 AWS 存储桶作为解决方案。
---
### Author:  [@dino](https://meta.discourse.org/u/dino)
#### Post date: [2020年二月4日 21:31 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/8 "2020-02-04T21:31:03Z")
@Falco 是的，我也被难住了。
包含 amazonaws 的 URL 出现的错误 specifically 针对文件上传，而非备份。对于备份，我只收到通用错误，所以我猜两者都因 URL 问题而失效。
你能想到其他可能吗？
@pfaffman 谢谢你的提示——我会看看更改 gem 的版本是否有帮助。
---
### Author:  [@FroggyC](https://meta.discourse.org/u/FroggyC)
#### Post date: [2020年二月21日 21:42 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/9 "2020-02-21T21:42:32Z")
嘿 @dino，那个方法最后有帮助吗？我也遇到了同样的问题，我快打算放弃了，准备切换到 Amazon S3。
---
### Author:  [@dino](https://meta.discourse.org/u/dino)
#### Post date: [2020年二月22日 06:31 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/10 "2020-02-22T06:31:26Z")
嘿 @FroggyC，
我实际上没时间调试这个问题，所以最终没有尝试更改 gem 版本。我改用了官方文档中的 Amazon S3 方法，一切立刻就能正常工作了。
很抱歉消息不太理想…
---
### Author:  [@FroggyC](https://meta.discourse.org/u/FroggyC)
#### Post date: [2020年二月23日 10:38 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/11 "2020-02-23T10:38:45Z")
谢谢。我想我们也得这么做。谢谢！
---
### Author:  [@overheadhunter](https://meta.discourse.org/u/overheadhunter)
#### Post date: [2020年四月3日 13:43 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/12 "2020-04-03T13:43:20Z")
我也遇到了同样的问题。有什么我们可以做的来帮助调试吗？
例如，通过 CLI 访问存储桶并发送日志文件？
`s3_region` 被忽略了吗？因为 Scaleway 使用的值与 AWS 不同（参见 [不同值](https://www.scaleway.com/en/docs/object-storage-feature/#-Core-Concepts)）。
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2020年四月4日 08:56 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/13 "2020-04-04T08:56:24Z")
您可以尝试联系 Scaleway——兼容性责任在他们身上。如果他们尚未完全兼容 AWS S3，应该修复这一问题。
---
### Author:  [@overheadhunter](https://meta.discourse.org/u/overheadhunter)
#### Post date: [2020年四月4日 10:03 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/14 "2020-04-04T10:03:47Z")
> [@codinghorror](#):
>
> 如果它们不完全兼容 AWS S3，就应该修复这个问题。
你暗示这是他们的责任，但你一直忽略了 @dino 的评论：
> [@Using Scaleway s3-compatible object storage](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/3?u=overheadhunter):
>
> That’s possible, but the url shouldn’t include [amazonaws.com](http://amazonaws.com) if I entered the endpoint - right?
只要（未经篡改的）`s3_endpoint` URL 未被直接使用，就很难让 Scaleway 相信错误在他们那边。尤其是其他 S3 客户端都能成功连接。
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2020年四月4日 10:11 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/15 "2020-04-04T10:11:13Z")
好的，请证明。请出示能证明这一点的文档和日志追踪记录。如果你能提供确凿的证据表明问题出在我们这边，我会查看。
---
### Author:  [@overheadhunter](https://meta.discourse.org/u/overheadhunter)
#### Post date: [2020年四月4日 13:46 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/16 "2020-04-04T13:46:38Z")
好的，这正是我刚才提到的意思：
> [@overheadhunter](#):
>
> 有什么我们可以帮忙调试的吗？
那么，我该如何配置 Discourse 以记录其 S3 连接尝试？一旦我们确认它要连接的确切 URL，我就可以拦截流量并分享结果。
---
### Author:  [@elle](https://meta.discourse.org/u/elle)
#### Post date: [2020年四月10日 10:21 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/17 "2020-04-10T10:21:26Z")
S3 上传/备份无法工作的原因是需要将区域设置为 `fr-par`（或 `nl-ams`），而这一设置只能通过绕过 Discourse 的 SiteSetting 验证来实现：
（通过 `./launcher enter app` 然后运行 `rails c`）
```plaintext
SiteSetting.find_by(name: 's3_region').update_attribute(:value, 'fr-par')
```
在此更改之后，上传和备份即可正常写入 Scaleway 对象存储。
[Scaleway 对象存储文档](https://www.scaleway.com/en/docs/object-storage-feature/#-Core-Concepts)
当然，这只是一个临时解决方案。一旦您通过 Web 管理界面重置或修改此站点设置，就无法将其恢复为可用状态（除非再次使用 Rails 控制台）。
我推测 AWS/S3 客户端应允许显式设置区域字符串（与当前 Web 管理界面的状态不同）。
此外，Discourse 中“EU (Paris)”下拉选项的值也具有一定的误导性，因为它对应的是 AWS 的命名规范 `eu-west-3`（或类似名称），而非 Scaleway 所期望的区域值。
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2020年四月10日 17:53 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/18 "2020-04-10T17:53:53Z")
啊。我们需要一个特殊的“S3 兼容区域”站点设置字段吗，@falco？这样用户就可以输入完全任意的（从亚马逊的角度来看是“虚构的”）区域。
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2020年四月10日 18:41 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/19 "2020-04-10T18:41:15Z")
不必如此。
使用 S3 兼容存储的用户需要设置 S3\_ENDPOINT 环境变量，该变量会覆盖 S3\_REGION。
>
我有一篇完整的教程，专门讲解如何在 DigitalOcean 的 S3 兼容存储上配置，但我正在等待 DigitalOcean 修复其 S3 CDN 中的一个漏洞，然后再发布该教程。
如果 Scaleway 的状况比 DigitalOcean 更好，我打算尝试一下，并基于此编写我的指南。
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2020年四月10日 18:48 UTC](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603/20 "2020-04-10T18:48:51Z")
> [@Falco](#):
>
> 使用 S3 克隆的用户需要设置 S3 Endpoint 环境变量，这会覆盖 S3 Region。
没错，但他们如何\_知道\_要这样做呢？现有站点设置的描述中是否提到了这一点？我认为应该提及。你能修改一下吗？
[下一頁](https://meta.discourse.org/t/using-scaleway-s3-compatible-object-storage/140603.md?page=2)