Astriel commented 11 months ago

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.

pxpm commented 11 months ago

Hey @Astriel. We also use Forge to deploy some of our projects. Actually our demo is deployed on forge https://demo.backpackforlaravel.com

Can you check if you have the file there at all ? Or is it trying to read a non existent file ?

Is phar support enable there ? Can you ran commands like composer ?

Cheers

Astriel commented 11 months ago

Hey @pxpm !

I've got it deloyed on many forge servers, but never had this error. The file is indeed existing :

I can run composer commands indeed, I did a composer dump-autoload.

Sounds like phar can not be executed in this folder. But it sounds like it's existing on the server

Sounds like a permission issue.

pxpm commented 11 months ago

Can you check if the permissions match the same permissions of the same file in other project ?

Shouldn't the file be inside the basset folder ?

Maybe php artisan basset:clear && php artisan basset:cache could solve this ?

Astriel commented 11 months ago

I already did this, every command seems to work fine, but still the same problem. Should I maybe delete the tar file ?

Astriel commented 11 months ago

No indeed about the permission, most of the time it's a 775 with forge user, but for this specific file : -rw-r--r-- 1 root root 1347113 Oct 11 11:14 source-sans-3.052R.tar.gz

Astriel commented 11 months ago

I've tried to put a 755 permission, also a 775, for root and or forge user ... But still facing the same problem.

Astriel commented 11 months ago

Hello @pxpm any feedback ? Could you check on our of your environment the permission on the file ? I also tried to do a composer update, and then switching to the core-uiv4 but still the same problem (even if this file is only used for the core-uiv2).

Astriel commented 10 months ago

Hey @pxpm ! Still pinging to have a feedback / an info. Still bugging on my side.

pxpm commented 10 months ago

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.

vdomah commented 9 months ago

got exact same error. tried php artisan basset:clear && php artisan basset:cache - not helped. tried set project permission from scratch - no effect

Astriel commented 9 months ago

I still need to try the disk changing method. I managed to put a chmod 755 on the file with the root user and after few days it seems to work, but after that got also some problem with basset which was not able to write on other folders such as gravatar for example etc ... Will try to keep you updated.

tibbsa commented 9 months ago

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?

tjarrett commented 8 months ago

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:

./artisan tinker --execute="Basset::bassetArchive(base_path('vendor/backpack/theme-coreuiv2/resources/assets/fonts/source-sans-3.052R.tar.gz'), 'source-sans-pro');"

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 storage first.

pxpm commented 7 months ago

Hey @tjarrett @tibbsa @Astriel @vdomah

This was automatically closed by automation. Sorry guys.

So, I've just pushed some code that will move the file to the storage before attempting to extract it. Do you think this will be enough to solve the issues your reported with the .tar file ?

Can any of you pull basset 1.2.3 and test if it works now on your side ?

Cheers