mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-08 03:09:39 +03:00
Unable to upload images to self hosted Minio S3 service #4894
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Rami-Pastrami on GitHub (Jul 31, 2024).
Attempted Debugging
Searched GitHub Issues
Describe the Scenario
I am trying to enable S3 image uploading to a private Minio instance, however every time I attempt to upload an image, I get an HTTP 500 error from book stack as well as an error fly-in on the top right stating that "An error occurred uploading the image"
In Debug mode, I caught the HTTP 500 error in the web console (which also appears out of debug mode but with less details). The full details from debug mode are:
League\Flysystem\UnableToCheckFileExistence
Unable to check existence for: uploads/images/gallery/2024-07/image.png
Stack trace (I believe this is the same as in the larvel log but including anyways)
Details
This seems almost like an authentication issue?
I can see in the Minio logs the following:
In other words, I see a GetObject twice, I dont see any mention of files being uploaded (checking the bucket contents also show it to be empty).
I double checked that the authorized keys / credentials are valid for this bucket, and I have other software that uses this minio s3 instance on other buckets that work fine. I even tried setting the bucket read/write permissions to public (meaning no auth needed to read or write to the entire bucket, which obviously isnt a proper solution but even this did not work.
Uploading files directly/manually to the bucket via the minio Web GUI and then pulling them from the domain externally as a direct link works fine on this public setting
I configured the .env file as per the documentation for non-amazon s3
https://www.bookstackapp.com/docs/admin/upload-config/
I found a discord discussion a few months ago that mentioning commenting out STORAGE_URL helped but it was not effective for me
given the logs mention a 403 and not a 404, this could be an authentication issue but given I have set this bucket to be public I am not sure what could still be causing it.
Thank you for any help, and please let me know if more info is needed!
Exact BookStack Version
v24.05.3
Log Content
Details
Hosting Environment
Bookstack running in docker on ubuntu server, minio running on a separate truenas instance. Both go through the same nginx reverse proxy but under separate subdomains. Both subdomains are behind cloudflare.
@ssddanbrown commented on GitHub (Jul 31, 2024):
Hi @Rami-Pastrami,
Do those minio 403 logs occur each time you try to upload?
Just want to be sure they're connected here.
If so, It makes sense for the error thrown. BookStack will initially be doing a GET to check if a file already exists, which correlates with the error and logs.
Does your S3 key or secret contain any special characters? If so, which?
@Rami-Pastrami commented on GitHub (Jul 31, 2024):
This happens every time, correct. Neither the key or secret contain any special characters, it is fully alphanumeric
@Rami-Pastrami commented on GitHub (Aug 8, 2024):
Still trying to figure out whats going on.
Pulled the docker image to get to bookstack v24.05.3, that didnt seem to do anything.
the name of my bucket had hyphens, so I switched to a bucket with a name consistent only of lower case letters, no change
I tried switching from using a user to login, to using a token to login to the user, and using a token directly. no change.
I changed the bucket back to "private" but customized the permissions so that anonymous public users can read the contents (the intended setup):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "s3:GetBucketLocation", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::[BUCKETNAME]" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::[BUCKETNAME]/*" ] } ] }Please let me know if there is anything else to try, this is a perplexing issue
@ssddanbrown commented on GitHub (Aug 9, 2024):
@Rami-Pastrami I performed a test run with Minio since it had been a while since I last tested that combo.
Could get things working although I could get the same error if not using a key for an actual user entry that has write access to the bucket.
I recorded the process end-to-end from a fresh stack so you could see exactly what I do:
https://foss.video/w/9noJP3x5gnmQ4bNUAg47qs
@Rami-Pastrami commented on GitHub (Aug 9, 2024):
Wow, thanks for the video walkthrough!
so TLDR I followed the steps provided and it fixed my issue in my particular use-case when connecting to Minio with a direct LAN IP, but it seems to error out in the above manner when connecting via external domain
Steps Taken:
At this point I confirmed that image uploading worked correctly, as well as viewing! I confirmed this test from both within the same LAN as the servers and externally over cellular.
I restored permissions instead of using global permissions on Minio account, everything continued working
However, if I change "STORAGE_S3_ENDPOINT" to use the external domain of my Minio instance, I end up with the same error. Switching back and forth between using the local IP and using the external one is the one singular value I can change to cause the error or not.
I am using the internal LAN IP for STORAGE_S3_ENDPOINT as per the video currently as it resolves the issue for my setup. However if Minio was being run externally, I am unsure if this work around would have worked.
If it means anything, my set up is as follows:
Minio / Bookstack running on 2 devices within the same lan -> shared NGINX reverse proxy -> NAT / router -> cloudflare -> each service has the same root domain but each have their own subdomain.
Cloudflare does have a limit of ~100 mb for single files, but my tested images were ~5 mb so I doubt that was any issue.
I am alright with having this Github issue be closed, but let me know if you have any questions.
Thanks for your help!
@ssddanbrown commented on GitHub (Aug 9, 2024):
So that makes me suspicious of the cloudflare and NGINX proxies involved, more so of Cloudflare.
Something to note is that access is authenticated with the
Authorizationheader.This being dropped/altered would result in the error you're seeing.
This can often occur if there are redirects involved in HTTP requests (clients will drop this to avoid leaking secrets).
Ensure your
STORAGE_S3_ENDPOINTprovides a complete direct route to the MINIO system.By that, I mean check things like protocol (
https://vshttp://) and (with/without) trailing slashes.If any parts inbetween (cloudflare/nginx) are performing redirects to handle these (to ensure slashes or upgrade to https) then that could be adding a redirect and potentially result in the
Authorizationheader being dropped.@ssddanbrown commented on GitHub (Dec 21, 2025):
Since it's been a while since the last response I'm going to go ahead and close this off.