basset: [Bug] unable to open new phar "/home/forge/default/vendor/backpack/theme-coreuiv2/resources/assets/fonts/source-sans-3.052R.tar" for writing
Bug report
What I did
I’ve deployed a new version of my project into production.
What I expected to happen
To be able to login on Backack.
What happened
I’ve got the following error when trying to go the Backpack login screen :
unable to open new phar "/home/forge/default/vendor/backpack/theme-coreuiv2/resources/assets/fonts/source-sans-3.052R.tar" for writing
What I’ve already tried to fix it
Changing the chmod for boostrap/cache and storage.
Context to replicate the bug - Backpack, Laravel, PHP, DB version
When I run php artisan backpack:version the output is:
### LARAVEL VERSION:
10.28.0.0
### BACKPACK PACKAGE VERSIONS:
backpack/basset: 1.2.1
backpack/crud: 6.2.4
backpack/devtools: 2.0.3
backpack/generators: v4.0.2
backpack/permissionmanager: 7.1.0
backpack/pro: 2.0.16
backpack/theme-coreuiv2: 1.2.2
backpack/theme-coreuiv4: 1.1.1
Project is deployed on Laravel Forge, using PHP 8.2.
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Comments: 15 (4 by maintainers)
This has been plaguing us for awhile now and I finally spent some time figuring out a work around (besides making vendor/backpack/theme-coreuiv2/resources/assets/fonts writable by our web server).
If we run this command, it resolves the issue:
I think something needs to change in BassetManager::bassetArchive such that it does the work in a directory that is expected to be writable by the web server – for example copy source-sans-3.052R.tar.gz to somewhere in
storagefirst.We are seeing this on a project that was just upgraded to L10/Backpack 6.3/pro 2.0.18. It is almost certainly a permissions issue, but I also find it a bit surprising that a package would ever assume it has write access to ‘vendor’. Chmoding the ‘resources’ folder to 777 got us past the first issue, but then we also received an error about not being able to create a directory in storage/app/public/basset.
On the second issue, the problem is this. When we deploy, artisan is running as the “app” user, not www-data. So running ‘artisan basset:cache’ results in files being created in storage/app/public/basset that are owned by app:app rather than ‘www-data:app’.
This begs a bigger question about which user artisan should run as on deployments or indeed what queue workers should run as — ala the discussion at https://stackoverflow.com/questions/59196317/laravel-file-permission-incompatibility-between-user-running-the-jobs-and-the-we – but this comes full circle back to, it is almost certainly a permissions issue.
A difficult one in a sense, because who is ever going to remember to sudo run ‘artisan’ as www-data to avoid the issue?
I am sorry @Astriel I was hopping someone would face the same issue.
I was not able to reproduce it, and nobody yet reported the same.
Our demo is hosted with forge too, in a digital ocean droplet.
Can you try using a completely different disk for basset like I suggested in this reply: https://github.com/Laravel-Backpack/basset/issues/104#issuecomment-1820677638
Let me know if that helps.