I wish it wasn't such a pain in the ass to debug why the fuck minio is throwing 403s at forgejo, when the access keys are correct.
-
I wish it wasn't such a pain in the ass to debug why the fuck minio is throwing 403s at forgejo, when the access keys are correct.
-
2024/11/21 19:25:14 ...s/storage/storage.go:176:initAttachments() [I] Initialising Attachment storage with type: minio
2024/11/21 19:25:14 ...les/storage/minio.go:97:NewMinioStorage() [I] Creating Minio storage at s3.theoden:forgejo with base path attachments/
2024/11/21 19:25:14 routers/init.go:62:mustInit() [F] code.gitea.io/gitea/modules/storage.Init failed: permission denied
2024/11/21 19:25:14 ...s/process/manager.go:231:remove() [T] Done 673f7b0a-26: Logger: xormThat's the forgejo side, with trace level logging. Very much not useful. The minio side is even less useful.
The bucket exists, the access keys should be fine (I can copy stuff to
s3.theoden/forgejo/attachments/withmc cp). I get the same error whether the directory exists or not.It might be failing at
getBucketVersioning, perhaps? -
Huh. Stracing forgejo suggests that we're not sending any authentication headers to minio? WTF.
-
Mngh. I'll debug this some other time. Not enough functioning braincells available right now.
-
The interesting part is that my server is running Forgejo 9.0.2 (official container image), and has S3 configured as storage. In my test environment, I'm also running 9.0.2 (self-built from the v9.0.2 tag), and the storage configuration is the same, apart from the URL and credentials.
This is a bit puzzling.
