starred/BookStack
1
0
Fork 0
mirror of https://github.com/BookStackApp/BookStack.git synced 2026-05-04 18:08:46 +03:00
Code Issues 784 Packages Projects Releases 15 Wiki Activity

open_basedir error with CHROOT and 'php artisan config:cache' #2820

New Issue
Closed
opened 2026-02-05 05:18:42 +03:00 by OVERLORD · 7 comments
OVERLORD commented 2026-02-05 05:18:42 +03:00
Owner
Copy Link

Originally created by @labor4 on GitHub (May 30, 2022).

Describe the Bug

Hi
I get a strange open_basedir error, related to CHROOT.

I am not sure if I created this problem by chance, since I didn't configure cache in .env, but issued the command during troubleshooting. Is this a bug, or normally not triggered, if cache is unconfigured?

When in chroot:
php artisan config:cache

...then opening my BookStack URL in Browser, produces:
Got error 'PHP message: PHP Fatal error: Uncaught ErrorException: file_exists(): open_basedir restriction in effect. File(/subdomains/bs.MYDOMAIN/resources/views/errors/500.blade.php) is not within the allowed path(s): (/var/www/vhosts/MYDOMAIN/:/tmp/) in /var/www/vhosts....

but it is really nested in the "allowed path". the true path is:
/var/www/vhosts/MYDOMAIN/subdomains/bs.MYDOMAIN/resources/views/errors/500.blade.php

I can fix it using:
php artisan config:clear

This is only present in a CHROOT

Thanks!

Steps to Reproduce

  • be in chrooted envirorment
  • no caching set up in .env
  • issue php artisan config:cache
  • open browser page

Expected Behaviour

no open_basedir error

Screenshots or Additional Context

pdf exporter is wkhtmltopdf

Browser Details

Brave, Safari

Exact BookStack Version

BookStack v22.04.2

PHP Version

php80 (both CLI and Web)

Hosting Environment

Ubuntu 18 LTS, Plesk 18.0.43

Originally created by @labor4 on GitHub (May 30, 2022). ### Describe the Bug Hi I get a strange **open_basedir error**, related to CHROOT. I am not sure if I created this problem by chance, since I didn't configure cache in ```.env```, but issued the command during troubleshooting. **Is this a bug, or normally not triggered, if cache is unconfigured?** **When in chroot**: ```php artisan config:cache``` ...then opening my BookStack URL in Browser, produces: ```Got error 'PHP message: PHP Fatal error: Uncaught ErrorException: file_exists(): open_basedir restriction in effect. File(/subdomains/bs.MYDOMAIN/resources/views/errors/500.blade.php) is not within the allowed path(s): (/var/www/vhosts/MYDOMAIN/:/tmp/) in /var/www/vhosts....``` **but it is really nested in the "allowed path"**. the true path is: ```/var/www/vhosts/MYDOMAIN/subdomains/bs.MYDOMAIN/resources/views/errors/500.blade.php``` I can fix it using: ```php artisan config:clear``` This is only present in a CHROOT Thanks! ### Steps to Reproduce - be in chrooted envirorment - no caching set up in ```.env``` - issue ```php artisan config:cache``` - open browser page ### Expected Behaviour no open_basedir error ### Screenshots or Additional Context pdf exporter is wkhtmltopdf ### Browser Details Brave, Safari ### Exact BookStack Version BookStack v22.04.2 ### PHP Version php80 (both CLI and Web) ### Hosting Environment Ubuntu 18 LTS, Plesk 18.0.43
OVERLORD added the 🐛 Bug label 2026-02-05 05:18:42 +03:00
OVERLORD commented 2026-02-05 05:18:48 +03:00
Author
Owner
Copy Link

@ssddanbrown commented on GitHub (May 30, 2022):

Hi @labor4,

The php artisan config:cache is not something we document or officially support. There can be side-affects to using this, the cache must be cleared on any configuration change.

I'm not too familiar with chroot environments, since I rarely use them, but to me this makes sense since chroot effectively changes where the root directory lies. Your shell environment sees the directly starting at a different point, so the paths don't align with the configured open_basedir setting.

@ssddanbrown commented on GitHub (May 30, 2022): Hi @labor4, The `php artisan config:cache` is not something we document or officially support. There can be side-affects to using this, the cache must be cleared on any configuration change. I'm not too familiar with chroot environments, since I rarely use them, but to me this makes sense since chroot effectively changes where the root directory lies. Your shell environment sees the directly starting at a different point, so the paths don't align with the configured `open_basedir` setting.
OVERLORD commented 2026-02-05 05:18:51 +03:00
Author
Owner
Copy Link

@labor4 commented on GitHub (May 30, 2022):

Thanks.
Understood.

Do you say that I need not worry that there will be a bad cache build-up over time that again creates wrong entries (Even if I never again use php artisan config:cache)?

@labor4 commented on GitHub (May 30, 2022): Thanks. Understood. Do you say that I need not worry that there will be a bad cache build-up over time that again creates wrong entries (Even if I never again use ```php artisan config:cache```)?
OVERLORD commented 2026-02-05 05:18:54 +03:00
Author
Owner
Copy Link

@ssddanbrown commented on GitHub (May 30, 2022):

Do you say that I need not worry that there will be a bad cache build-up over time that again creates wrong entries (Even if I never again use php artisan config:cache)?

Not sure I understand. There's no build-up in regards to this cache over time. Running php artisan config:cache simply snapshots and stores the current configuration in a more efficient format. You can use this if you really want but you'll need to remember to re-run this command if you ever change a .env option and also after updates.

@ssddanbrown commented on GitHub (May 30, 2022): > Do you say that I need not worry that there will be a bad cache build-up over time that again creates wrong entries (Even if I never again use php artisan config:cache)? Not sure I understand. There's no build-up in regards to this cache over time. Running `php artisan config:cache` simply snapshots and stores the current configuration in a more efficient format. You can use this if you really want but you'll need to remember to re-run this command if you ever change a `.env` option and also after updates.
OVERLORD commented 2026-02-05 05:19:02 +03:00
Author
Owner
Copy Link

@labor4 commented on GitHub (May 30, 2022):

Thanks. I'm not sure either.
This would suggest that php artisan config:cache would introduce absolute paths in a way that overrides the chroot substitution of Plesk/FPM. Sounds strange.

In any case I'd be glad if I could completely ignore this.
Maybe I should check at the laravel community for this question.

@labor4 commented on GitHub (May 30, 2022): Thanks. I'm not sure either. This would suggest that ```php artisan config:cache``` would introduce absolute paths in a way that overrides the chroot substitution of Plesk/FPM. Sounds strange. In any case I'd be glad if I could completely ignore this. Maybe I should check at the laravel community for this question.
OVERLORD commented 2026-02-05 05:19:08 +03:00
Author
Owner
Copy Link

@ssddanbrown commented on GitHub (May 30, 2022):

To be honest, I don't think this error is anything specific to the php artisan config:cache command.
I think it's simply that the open_basedir has been configured with a path that's no longer applicable when in a chroot environment.

@ssddanbrown commented on GitHub (May 30, 2022): To be honest, I don't think this error is anything specific to the `php artisan config:cache` command. I think it's simply that the `open_basedir` has been configured with a path that's no longer applicable when in a chroot environment.
OVERLORD commented 2026-02-05 05:19:10 +03:00
Author
Owner
Copy Link

@labor4 commented on GitHub (May 30, 2022):

Ah right. No, I tried and changed/ added a working path to open_basedir, but then it allows and understands /subdomains/bs.MYDOMAIN as absolute as in "outside chroot".
But I guess this is maybe FPM related. There should be a prefix happening somewhere. FPM seems the right authority for that. Or PHP-CLI doesn't reflect this.
Thanks for your time.
Regards!

@labor4 commented on GitHub (May 30, 2022): Ah right. No, I tried and changed/ added a working path to ```open_basedir```, but then it allows and understands ```/subdomains/bs.MYDOMAIN``` as absolute as in "outside chroot". But I guess this is maybe FPM related. There should be a prefix happening somewhere. FPM seems the right authority for that. Or PHP-CLI doesn't reflect this. Thanks for your time. Regards!
OVERLORD commented 2026-02-05 05:19:16 +03:00
Author
Owner
Copy Link

@labor4 commented on GitHub (May 30, 2022):

Oh my. Maybe it's $_SERVER['DOCUMENT_ROOT'] missing in php-cli...
This one is never defined in PHP-CLI. Could be.
Via Browser it holds the full /var/www/vhosts/MYDOMAIN/subdomains/bs.MYDOMAIN
Thanks for the hint.

@labor4 commented on GitHub (May 30, 2022): Oh my. Maybe it's ```$_SERVER['DOCUMENT_ROOT']``` missing in php-cli... This one is never defined in PHP-CLI. Could be. Via Browser it holds the full ```/var/www/vhosts/MYDOMAIN/subdomains/bs.MYDOMAIN``` Thanks for the hint.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
🎨 Design
📖 Docs Update
🐛 Bug
🐛 Bug
:cat2:🐈 Possible duplicate
💿 Database
☕ Open to discussion
💻 Front-End
🐕 Support
🚪 Authentication
🌍 Translations
🔌 API Task
🏭 Back-End
⛲ Upstream
🔨 Feature Request
🛠️ Enhancement
🛠️ Enhancement
🛠️ Enhancement
❤️ Happy feedback
🔒 Security
🔍 Pending Validation
💆 UX
📝 WYSIWYG Editor
🌔 Out of scope
🔩 API Request
:octocat: Admin/Meta
🖌️ View Customization
❓ Question
🚀 Priority
🛡️ Blocked
🚚 Export System
♿ A11y
🔧 Maintenance
> Markdown Editor
pull-request
Mirrored from GitHub Pull Request
No Label 🐛 Bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#2820
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?