File Storage Permissions issue #5009

New Issue

OVERLORD · 2026-02-05T09:33:20+03:00

OVERLORD commented

2026-02-05 09:33:20 +03:00

Originally created by @Lockyc on GitHub (Oct 16, 2024).

Describe the Bug

Hi Dan,

Fantastic product, we've been using BookStack and have been a GitHub sponsor for a while.
I've recently changed our hosting setup, which has caused a bit of friction with how BookStack handles file uploads.

I understand that my setup is not officially supported, that's fine.

I'm now running the linuxserver docker container on Google Cloud run.
For disk, the only real option is to mount a Google Storage bucket.
I've mounted it at /config as per linuxserver guide, using STORAGE_TYPE=local.

This is fine and works as to be expected until you go to upload files.
I have only been trying images, as that is our primary use case.

When you upload an image, the upload fails with something along the lines of.

could not be uploaded to. Ensure it is writable to the server.

The logs state

[2024-10-07 03:17:48] production.ERROR: Error when attempting image upload:Unable to set visibility for file gallery/2024-10/cleanshot.png.

The only thing is, the file has been uploaded successfully, I can access it directly from the bucket.

Since this was the case, and my setup wouldn't be officially supported, I figured I'd go down the s3 bucket route.
So I created a new Google Cloud Bucket to store only the file uploads.
Which I also understand would not be fully supported as it is not proper s3 but Google's interoperable version.
I configured everything as per your documentation.
The cutover was seamless until I uploaded images again.
I got the same "could not be uploaded to. Ensure it is writable to the server." error.
So I checked the logs.

[2024-10-16 05:08:36] production.ERROR: Error when attempting image upload:Unable to write file at location: uploads/images/gallery/2024-10/cleanshot-2024-10-16-at-16-08-24.png. Error executing "PutObject" on "https://storage.googleapis.com/####/uploads/images/gallery/2024-10/cleanshot-2024-10-16-at-16-08-24.png"; AWS HTTP error: Client error: `PUT https://storage.googleapis.com/####/uploads/images/gallery/2024-10/cleanshot-2024-10-16-at-16-08-24.png` resulted in a `400 Bad Request` response:
<?xml version='1.0' encoding='UTF-8'?><Error><Code>InvalidArgument</Code><Message>Invalid argument.</Message><Details>Ca (truncated...)
 InvalidArgument (client): Invalid argument. - <?xml version='1.0' encoding='UTF-8'?><Error><Code>InvalidArgument</Code><Message>Invalid argument.</Message><Details>Cannot insert legacy ACL for an object when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access</Details></Error>

I have fixed this by changing the access control from "Uniform" to "Fine-grained".

The reason I log this issue, is in both cases where the uploads fail it seems It's because BookStack is trying to set file permissions when it shouldn't be.

Ultimately, because our BookStack instance is private, I would prefer not to have our files public accessible on the internet.
But everything is working now.

Keep up the good work!

Steps to Reproduce

Detailed above

Expected Behaviour

Detailed above

Screenshots or Additional Context

No response

Browser Details

No response

Exact BookStack Version

v24.10 - linuxserver/bookstack:v24.10-ls169

Originally created by @Lockyc on GitHub (Oct 16, 2024). ### Describe the Bug Hi Dan, Fantastic product, we've been using BookStack and have been a GitHub sponsor for a while. I've recently changed our hosting setup, which has caused a bit of friction with how BookStack handles file uploads. I understand that my setup is not officially supported, that's fine. I'm now running the linuxserver docker container on Google Cloud run. For disk, the only real option is to mount a Google Storage bucket. I've mounted it at /config as per linuxserver guide, using ```STORAGE_TYPE=local```. This is fine and works as to be expected until you go to upload files. I have only been trying images, as that is our primary use case. When you upload an image, the upload fails with something along the lines of. > could not be uploaded to. Ensure it is writable to the server. The logs state ```[2024-10-07 03:17:48] production.ERROR: Error when attempting image upload:Unable to set visibility for file gallery/2024-10/cleanshot.png. ``` The only thing is, the file has been uploaded successfully, I can access it directly from the bucket. Since this was the case, and my setup wouldn't be officially supported, I figured I'd go down the s3 bucket route. So I created a new Google Cloud Bucket to store only the file uploads. Which I also understand would not be fully supported as it is not proper s3 but Google's interoperable version. I configured everything as per your documentation. The cutover was seamless until I uploaded images again. I got the same "could not be uploaded to. Ensure it is writable to the server." error. So I checked the logs. ``` [2024-10-16 05:08:36] production.ERROR: Error when attempting image upload:Unable to write file at location: uploads/images/gallery/2024-10/cleanshot-2024-10-16-at-16-08-24.png. Error executing "PutObject" on "https://storage.googleapis.com/####/uploads/images/gallery/2024-10/cleanshot-2024-10-16-at-16-08-24.png"; AWS HTTP error: Client error: `PUT https://storage.googleapis.com/####/uploads/images/gallery/2024-10/cleanshot-2024-10-16-at-16-08-24.png` resulted in a `400 Bad Request` response: <?xml version='1.0' encoding='UTF-8'?><Error><Code>InvalidArgument</Code><Message>Invalid argument.</Message><Details>Ca (truncated...) InvalidArgument (client): Invalid argument. - <?xml version='1.0' encoding='UTF-8'?><Error><Code>InvalidArgument</Code><Message>Invalid argument.</Message><Details>Cannot insert legacy ACL for an object when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access</Details></Error> ``` I have fixed this by changing the access control from "Uniform" to "Fine-grained". ![CleanShot 2024-10-16 at 16 42 57](https://github.com/user-attachments/assets/6b459b80-57a3-4441-aa4d-65cd6d100227) The reason I log this issue, is in both cases where the uploads fail it seems It's because BookStack is trying to set file permissions when it shouldn't be. Ultimately, because our BookStack instance is private, I would prefer not to have our files public accessible on the internet. But everything is working now. Keep up the good work! ### Steps to Reproduce Detailed above ### Expected Behaviour Detailed above ### Screenshots or Additional Context _No response_ ### Browser Details _No response_ ### Exact BookStack Version v24.10 - linuxserver/bookstack:v24.10-ls169

OVERLORD added the 🐛 Bug label 2026-02-05 09:33:20 +03:00

OVERLORD closed this issue

2026-02-05 09:33:21 +03:00

OVERLORD commented

2026-02-05 09:33:24 +03:00

@ssddanbrown commented on GitHub (May 5, 2025):

Hi @Lockyc,
Thanks for reporting in such detail.
I had also received similar reports for other environments (Azure storage, some other s3 scenarios).

I have attempted to mostly address this via #5601.
As of that PR, permission setting is not essential and failure to set permissions won't break the general process.
BookStack will still attempt to set permissions, to retain behaviour compatibility, but failure is now caught with a warning added to the app logs.

I have tested this works via a mounted GCS bucket (mounted as another user but with permissive permissions).
This was a scenario where I could replicate your originally reported permissions error within.

These changes will be part of the next BookStack patch release, so I therefore close this off.
If the log messages become problematic, then maybe we can think about adding a new option to control the attempt but I'll await for that to be raised as an actual issue, but the impact of a few log lines per image upload should be minimal.

@ssddanbrown commented on GitHub (May 5, 2025): Hi @Lockyc, Thanks for reporting in such detail. I had also received similar reports for other environments (Azure storage, some other s3 scenarios). I have attempted to mostly address this via #5601. As of that PR, permission setting is not essential and failure to set permissions won't break the general process. BookStack will still attempt to set permissions, to retain behaviour compatibility, but failure is now caught with a warning added to the app logs. I have tested this works via a mounted GCS bucket (mounted as another user but with permissive permissions). This was a scenario where I could replicate your originally reported permissions error within. These changes will be part of the next BookStack patch release, so I therefore close this off. If the log messages become problematic, then maybe we can think about adding a new option to control the attempt but I'll await for that to be raised as an actual issue, but the impact of a few log lines per image upload should be minimal.

OVERLORD commented

2026-02-05 09:33:26 +03:00

@Lockyc commented on GitHub (May 6, 2025):

Fantastic, thanks @ssddanbrown

@Lockyc commented on GitHub (May 6, 2025): Fantastic, thanks @ssddanbrown

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#5009