mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
secure image storage not working: images are not where expected #1051
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 @abossert on GitHub (Feb 20, 2019).
Describe the bug
I have turned on the secure image storage (STORAGE_TYPE=local_secure) and copied all of the contents of the $root/public/uploads/images to $root/storage/uploads/images as shown in the security instructions followed by a restart of the php-fpm service. I tried this once before with a "move" rather than a copy, but got the same results. When I copied the folder rather than moving it, I saw that existing images were still visible, but uploading new ones show no errors (I see a success message for the upload in the UI and also a successful POST in the Nginx access log, but there is a broken image link in the UI and an error as follows:
the end result is that with secure image storage, I am unable to access any images that have been uploaded...the errors seem to relate specifically to thumbnails (note the "thumbs-150-150" subdirectory), here is the SQL query that is supposedly inserting the image...from my browser developer console:
but the error message I am seeing in the logs shows:
When I do a filesystem search, I see that the file is where I would expect it to be (based on the secure storage setting) here:
So, what am I missing?...it seems like the application is still looking for the images in the orginal location rather than the new one.
For good measure, here is my .env file:
Steps To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect images uploaded to be accessible just as before when secure image storage was not turned on.
Screenshots
Here is a screeshot...just in case my description is not as clear as I think it is.
Your Configuration (please complete the following information):
@ssddanbrown commented on GitHub (Feb 20, 2019):
Hi @abossert, Sorry to hear you are experiencing issues.
Are you seeing this in webserver logs or the application logs? Would you be able to provide the whole log message?
Just trying to get an idea of whether your currently requests are even hitting the application or if they're directly being served by nginx.
@abossert commented on GitHub (Feb 20, 2019):
Those errors are in the nginx log...here is a full set of errors:
The application logs don't seem to have anything in them...
@ssddanbrown commented on GitHub (Feb 20, 2019):
@abossert Thanks, It possibly looks like nginx is fully handling the request, and the request is never hitting the app itself. Are you able to post your nginx config at all?
@abossert commented on GitHub (Feb 20, 2019):
Here is the nginx config:
and here is the bookstack portion:
@ssddanbrown commented on GitHub (Feb 21, 2019):
@abossert The image requests may be getting caught by the last matching block:
Can you, at least temporarily, remove this block and see if that enables the images to work as expected?
@abossert commented on GitHub (Feb 21, 2019):
YES!!! That did it...So, the big question is: is that block really necessary?
@ssddanbrown commented on GitHub (Feb 21, 2019):
@abossert Awesome!
No, the block isn't strictly necessary but it does add caching to images which can benefit load performance and it prevents image requests filling up the access log.
Not tested this but you might be able to alter that block to the following to keep the benefits:
@abossert commented on GitHub (Feb 21, 2019):
That seems to work just fine...Thanks again!
@ssddanbrown commented on GitHub (Feb 21, 2019):
Great, I'll close this off now since it seems to be resolved.