感谢您的感谢！我确实标记了需要版主关注，因为当时我没有编辑权限，但现在由于我发布的帖子，我已经获得了权限。这真是事与愿违，不是吗？
但在我在 MinIO 部分之外发布全局公告之前，我们能否确认 Discourse 整体不再支持基于非域名的路径，就像我编辑时发现的这个帖子一样？
如果我们知道 Discourse 整体不支持路径模式（即 minio.server.com/BUCKET/foo/bar/... 路径），而只支持域名路径（即 BUCKET.minio.server.com/foo/bar/...），那么我们就可以在 wiki 中发布一个全局通知，我很乐意这样做——但我需要从比我（一个普通的社区成员）高很多的人那里得到确认，这确实是 Discourse 的要求。如果是这样，我就可以编辑进去，否则……嗯，我就会把它留作 MinIO 要求的说明。
MinIO 是唯一一个有使用现已弃用的 S3 路径样式的历史的流行 S3 克隆，所以我认为它不值得全局警告，仅在 MinIO 部分就足够了。
谢谢你，Falco，我已经把它放在 MinIO 的必要条件中了，但也要特别强调那个注意事项部分，因为上面链接的帖子提到了我为什么再次提出这个问题。
似乎出现了一个问题：
输入
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
重建：
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -E -u discourse bundle exec rake s3:upload_assets failed with return #<Process::Status: pid 2064 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
你能否遵循指导并
已向 OP 添加了一个清理 S3 中旧资产的步骤。应在 GCP 以外的所有地方正常工作。
在 rake s3:migrate_to_s3 上上传的 170K 文件中，大部分都已成功，但我认为有 12 个出现了这个错误：
: 不支持的罐装 ACL 值 'private' (Aws::S3::Errors::InvalidArgument)
也许那些文件在 PM 中？有什么办法可以修复它们吗？
嘿 @Falco。这有意义吗？我正在查看回复，以确保它们已被处理，以便我们可以启用此主题上的“30 天后删除”功能。
我检查了一些标记为私有的上传，它们都在常规主题中，所以我无法弄清楚为什么它们被标记为安全。（安全上传未设置？）
见上文
安全上传仅支持 AWS S3，因此确实无法与任何克隆产品配合使用。
说得通。我已将 OP 的顶部更新为该信息。您知道为什么本地上传会在未启用 S3 或安全上传的网站上被标记为安全吗？
有人之前启用过，但看到它不起作用后又撤销了？
我认为使用 Upload.where(secure: true).update_all(secure: false) 可能会解决此问题，即上传到 Cloudflare R2。我会在此消息被删除之前尝试解决它（但我已在 OP 中添加了注释）。
嗯，我们没有任何安全上传。我想我会试试 Cloudflare R2，因为它们的免费额度相当慷慨，而且它们有一个（测试版）S3 迁移器。我想我会弄清楚的，但你有没有看到 R2 最后是否正常，@pfaffman？
我已无法记起问题是在我尝试上传图片时出现的，还是在我刚上传新图片时出现的。仔细想想，我认为我是在一个全新的网站上测试的。
迁移到不同的 S3 平台相当棘手。有一些关于这方面的主题，但如果你想使用 Cloudflare R2，我建议你先在测试网站上试用一下；很有可能它无法正常工作。
它有点奏效，但尚未准备好投入生产使用。
我有一个旧的 Discourse 2.7 本地开发安装程序，它运行正常，即图像上传、CDN 使用以及在为 Cloudflare R2 设置时备份到私有存储桶。我已更新到最新的 2.9 版本（就像我们的论坛使用的那样），它似乎在 Jobs::UpdateGravatar 的追赶处理中失败，因为它错误地使用了 Cloudflare 的存储桶表示法，试图将 gravatar 远程图像缓存到 R2。例如（我的 R2 上的存储桶名称是 ‘uploads’）：
Upload Update (0.3ms) UPDATE "uploads" SET "url" = '//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg', "updated_at" = '2022-12-12 20:44:02.929494', "etag" = '9c02b086b2aa5e2088ed44e1017fa63e' WHERE "uploads"."id" = 3
所以我会启动 UI，在我本地测试/开发设置中的头像将指向
//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg
所以我的最佳猜测是 S3 可以接受存储桶点表示法，而 Cloudflare R2 不行，或者也许 gravatar 缓存需要使用 S3 CDN 值而不是？这很可惜，因为它似乎非常接近了。
我收到了 Cloudflare 的回复，对于 R2，在他们正确实现对象 ACL 之前，他们已将其更改为在获取到他们尚不支持的属性中的值时返回 200。R2 中这种改变的行为似乎是在 11 月底。这显然不理想（它在一个公共存储桶中，但 API 要求它是私有的），但意味着对于这个问题，它现在“可以工作”了。
哦！这听起来确实很有希望。不过，我认为您可能需要一个单独的存储桶来上传文件，尽管要猜出备份文件的文件名会相当困难。
我会尽快看看这个问题。
我确实使用了单独的上传和备份存储桶，而且似乎运行正常，因为备份 R2 存储桶未设置为公开，并且 Discourse 通过管理员界面在其中成功写入了一个压缩备份。我下载并查看了一下，看起来还算正常（虽然不像实际恢复那样，但对于周一来说足够了）。我的上传存储桶我已经用自定义域设置测试了 S3_CDN，并且运行良好。
老实说，我无法确定我的 2.9 版本在 ember-cli 中无法渲染 UI 的原因（在创建管理员用户后界面一片空白），但这可能很快就会被你发现问题所在。
编辑：哦，似乎它正试图从 Pseudo-S3/R2 加载插件 JavaScript 资源，例如很多像 assets/locales/en.br.js 这样的文件 404 错误。
我尝试运行 bundle exec rake s3:upload_assets 没有成功，所以这是我目前最好的线索。
编辑2：是的，这与资源有关，因为如果我清除 DISCOURSE_S3_CDN_URL，UI 就会加载。我现在将尝试手动上传资源。
编辑3：问题似乎只是应用程序需要预编译资源，而 DISCOURSE_S3_CDN_URL 指向的位置，在本地开发环境中这并不常见。我对 @pfaffman 的发现很感兴趣，因为我认为这在通过 after_assets_precompile 钩子使用 R2 的标准 Docker 部署的自托管实例中会起作用。
是的。本地开发环境使用 CDN？我无法想象它能奏效。这听起来确实应该能在生产环境中奏效。
是的，回顾一下，在开发环境中这并不令人意外。我想我没料到的是，即使将 DISCOURSE_S3_CDN_URL 设置为 Cloudflare R2 CDN，然后将 DISCOURSE_CDN_URL 设置为空（或本地或 ngrok），它仍然会尝试使用 Cloudflare 的拉取 URL 来获取预编译资源等，而不仅仅是上传/图片。我认为在生产环境中，在一个合适的容器里它应该能正常工作，所以我可能会快速尝试一下。我的计划将是暂时将媒体上传设置为 TL4，在 app.yaml 中将 ID 等切换到 Cloudflare，进行测试，如果效果好，就保留 R2，然后使用 rclone 将所有现有的 S3 对象迁移过去——之后我会重新烘焙帖子，希望一切都会好起来 
。