mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 16:49:47 +03:00
Default permissions on public-directories giving white screen #4228
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 @memetoec on GitHub (Sep 20, 2023).
Attempted Debugging
Searched GitHub Issues
Describe the Scenario
I had a todo upgrading BookStack from v23.01.1 to v23.08.3. While doing so I had to solve some issues regarding composer and PHP version, when that was in place everything seemed to go well.
When all routines was done and I was ready to check the application, I was met with a white screen. I checked the logs for php-fpm and got this error message:
Details
On line 3 laravel is complaining about permissions, so I followed this routine -> filesystem-permissions
After doing so, nothing happened. I search on similar error messages where people said to clear cache both in browser and application.
I ended up clearing my browser cache and doing the following commands,
Still, I had a white screen viewing nothing. Then I did what all sysadmins are tought NOT to do, and that is to give 777 to publicly faced directories.
Then, everything worked!
BUT, I'm not happy having storage, bootstrap/cache and public/uploads with permissions set to 777.
My question now is, is this intentional? Or have I done something wrong along the upgrade?
What I did:
Exact BookStack Version
v23.08.3
Log Content
Details
Hosting Environment
My Environment:
OS: Rocky Linux 8.x
Hypervisor: VMWare
PHP version: 8.2 - REMI repo
NGINX: nginx/1.14.1
Composer: 2.5.1 2022-12-22 15:33:54
@ssddanbrown commented on GitHub (Sep 21, 2023):
Did you change
www-datato suit your operating system?I don't think
www-datais used by RHEL based systems. You'd have to check what nginx is running as.@memetoec commented on GitHub (Sep 21, 2023):
Yes, I'm using nginx as user and group.
My nginx.conf has nginx as system user defined. I have changed php-fpm to use nginx as user and group as well.
As you can see, my folders and files have 777 (not the way I want it BUT only settings that work). User is nginx:nginx.
@ssddanbrown commented on GitHub (Sep 21, 2023):
If you're sure the user/group is aligned to webserver/php process owner, then the other thing it can often be on RHEL based systems is SELinux. You could try temporarily disabling SELinux to assess if that's the cause.
@memetoec commented on GitHub (Sep 25, 2023):
Hi!
SELinux is disabled on this server,
It's not that either. What I think is weird is that the application was not responding until I set 777 on all public folders.
What's more strange is that people are not able to upload files either, some users (not all) have problems upload images to articles.
@ssddanbrown commented on GitHub (Sep 25, 2023):
Outside of those two elements (file permissions and SELinux), I'm not sure what else it would be.
Can you upload an image then list out then
ls -althat directory, to double check the user and group being used by BookStack when creating these? There could be something else involved due to thephp-fpmprocess, rather than it just being nginx.@memetoec commented on GitHub (Sep 26, 2023):
Hi!
I did that earlier today, and got the following output:
I'll add our folder structure as well, so you can see if anything is not correct:
The only folder that is directly affected is the 2023-09 (I did the upgrade late last week)
I checked your documentation for PHP-packages and had all required packages installed. Here is the list of installed PHP-packages,
I have also checked some parameters in php.ini. I did adjust some thresholds to upload size and execution time, despite that those settings doesn't have anything to do with permissions on folder ^^
@ssddanbrown commented on GitHub (Sep 26, 2023):
Just as a test, do things stop working again if you set
755permissions on that2023-09folder?If not, try setting it for the whole,
public/uploadsfolder again.Then others, until it stops working.
I don't see why recursive
nginx:nginxand755won't work for the required directories at this point.One extra point,
nginxwould also need read+execute on all parent directories. If that's something that changed when you started setting777, that could be the cause.@ssddanbrown commented on GitHub (Oct 14, 2023):
Since it's been a few weeks I'll close this off. If further insight can be provided or desired, feel free to comment and this can be re-opened if required.