New issue on Laravel 10

[vesper8]

This one is difficult to describe so I'm not sure where to start.

I very recently ran composer install on my project which uses Laravel 10 and runs on a server with PHP 8.2. I noticed that a lot of Symfony deps were updated.

And all of a sudden I started getting this really obscure error

is_executable(): open_basedir restriction in effect. File(/usr/bin/php) is not within the allowed path(s): (/home/forge/:/tmp)

After much time wasting and trouble shooting, I was able to narrow it down to this package pionl/laravel-chunk-upload which is pulled in because I'm using oneduo/nova-file-manager

Specifically this is part of my trace

in [/home/forge/redacted/releases/352/vendor/pion/laravel-chunk-upload/src/Providers/ChunkUploadServiceProvider.php ](file:///home/forge/redacted/releases/352/vendor/pion/laravel-chunk-upload/src/Providers/ChunkUploadServiceProvider.php#L37)-> command (line 37)
                
// Get the scheduler instance                
/** @var Schedule $schedule */                
$schedule = $this->app->make(Schedule::class);               
 // Register the clear chunks with custom schedule                
$schedule->command('uploads:clear')                    
->cron(Arr::get($scheduleConfig, 'cron', '* * * * *'));            
});        
}        
$this->registerHandlers($config->handlers());

After removing oneduo/nova-file-manager then things are back to working.

This was working fine before the latest symfony updates.

So something to keep a look out for..

[pionl]

I would say that problem is with server setup tmp folder setting.

The package does not use directly /tmp folder but uploading probably does.

You can disable the clean schedule for further "localization" of the problem https://github.com/pionl/laravel-chunk-upload/blob/master/config/chunk-upload.php

[yormy]

I can confirm this problem

[vesper8]

I want to mention that with this package installed, I cannot even boot up the welcome page. I don't have to be in Nova. In fact I was not even using oneduo/nova-file-manager. I had published its config file and installed it with composer but that was it, I was not actually using it anywhere at all, just the presence of it was causing my entire Laravel application to return error 500.

This was not happening before the latest updates. Something changed with the latest minor Symfony updates.

[Rezrazi]

@vesper8 can you share the full stacktrace please? I'm interested to understand what's happening as it might affect other users

[vesper8]

Sure thing. Here it is. This error happens just from installing oneduo/nova-file-manager using composer. Nothing published, no actual references to it anywhere.

ErrorException:
is_executable(): open_basedir restriction in effect. File(/usr/bin/php) is not within the allowed path(s): (/home/forge/:/tmp)

  at /vendor/symfony/process/ExecutableFinder.php:76
  at Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'is_executable(): open_basedir restriction in effect. File(/usr/bin/php) is not within the allowed path(s): (/home/forge/:/tmp)', '/vendor/symfony/process/ExecutableFinder.php', 76)
     (/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php:254)
  at Illuminate\Foundation\Bootstrap\HandleExceptions->Illuminate\Foundation\Bootstrap\{closure}(2, 'is_executable(): open_basedir restriction in effect. File(/usr/bin/php) is not within the allowed path(s): (/home/forge/:/tmp)', '/vendor/symfony/process/ExecutableFinder.php', 76)
  at is_executable('/usr/bin/php')
     (/vendor/symfony/process/ExecutableFinder.php:76)
  at Symfony\Component\Process\ExecutableFinder->find('php', '', array('/usr/bin'))
     (/vendor/symfony/process/PhpExecutableFinder.php:84)
  at Symfony\Component\Process\PhpExecutableFinder->find(false)
     (/vendor/laravel/framework/src/Illuminate/Console/Application.php:87)
  at Illuminate\Console\Application::phpBinary()
     (/vendor/laravel/framework/src/Illuminate/Console/Application.php:108)
  at Illuminate\Console\Application::formatCommandString('uploads:clear')
     (/vendor/laravel/framework/src/Illuminate/Console/Scheduling/Schedule.php:143)
  at Illuminate\Console\Scheduling\Schedule->command('uploads:clear')
     (/vendor/pion/laravel-chunk-upload/src/Providers/ChunkUploadServiceProvider.php:37)
  at Pion\Laravel\ChunkUpload\Providers\ChunkUploadServiceProvider->Pion\Laravel\ChunkUpload\Providers\{closure}(object(Application))
     (/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:1071)
  at Illuminate\Foundation\Application->fireAppCallbacks(array(object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure)))
     (/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:1014)
  at Illuminate\Foundation\Application->boot()
     (/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/BootProviders.php:17)
  at Illuminate\Foundation\Bootstrap\BootProviders->bootstrap(object(Application))
     (/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:261)
  at Illuminate\Foundation\Application->bootstrapWith(array('Illuminate\\Foundation\\Bootstrap\\LoadEnvironmentVariables', 'Illuminate\\Foundation\\Bootstrap\\LoadConfiguration', 'Illuminate\\Foundation\\Bootstrap\\HandleExceptions', 'Illuminate\\Foundation\\Bootstrap\\RegisterFacades', 'Illuminate\\Foundation\\Bootstrap\\RegisterProviders', 'Illuminate\\Foundation\\Bootstrap\\BootProviders'))
     (/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php:186)
  at Illuminate\Foundation\Http\Kernel->bootstrap()
     (/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php:170)
  at Illuminate\Foundation\Http\Kernel->sendRequestThroughRouter(object(Request))
     (/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php:144)
  at Illuminate\Foundation\Http\Kernel->handle(object(Request))
     (/public/index.php:51)   

[Rezrazi]

This seems like an upstream issue unrelated to this package. You'd experience the same issue if you registered a random command in your scheduler without having this package installed. Scheduler is registered early in the application lifecycle, if it fails, your whole application fails.

Can you share the exact version of your installed symfony/process package? Can you check that nothing changed at the host level? Some configuration that was altered recently intentionally or accidentally?

[Rezrazi]

Additionally, can you share the output of this? ´´´php $allowedPaths = ini_get('open_basedir');

dd($allowedPaths); ´´´

You can run it in artisan tinker

I suspect a host/server misconfiguration. Are you able to reproduce it locally too?

[yormy]

I noticed it when I do a composer update. Reverting to the previous composer.lock... all works fine.. .upgrading and it breaks very early on in the request cycle

[Rezrazi]

@yormy can you delta the versions of symfony/process in both locks? I think it's worth opening an issue upstream at Symfony if a minor version caused a breaking change 👍

[vesper8]

ini_get('open_basedir') returns empty.

symfony/process is v6.4.0

I did run a sudo apt update && upgrade a few days ago.. that might have played a role

However, I should note that I have also tried rolling back to a few commits ago, where I do have oneduo/nova-file-manager installed.. and on that older commit there is no issue.. so I think that rules out a server issue doesn't it?

[vesper8]

The last working commit that works had this in the lock file:

"symfony/process": "^5.4|^6.0",

And now it contains "symfony/process": "^5.4|^6.0|^7.0",

I notice that a whole bunch of symfony dependencies just changed in a similar way

I should also mention that I'm not in the habit of running composer update, instead I have an aliased recomposer function that deletes the lock, deletes the vendor folder and reinstalls afresh from composer.json