mkdir(): Permission denied

[ingria]

I'm having this error on latest Tinker and Laravel, when attempting to call artisan tinker.

In Configuration.php line 352:

  [ErrorException]            
  mkdir(): Permission denied

After some investigations it turned out that Psysh is trying to mkdir /run/user/0/psysh, which is not accessible.

Possibly related to #33

[749]

+1 got the same problem here I posted it in the psysh as well: https://github.com/bobthecow/psysh/issues/443

oddly enough it works on laravel homestead, but not in my server

[fer-ri]

Same with me :+1:

[nicolashuber]

Same issue here too

[franky-ds]

Same issue here on Cloudlinux OS

php artisan tinker -vvvv mkdir() at /var/www/vhosts/domain.com/laravel/vendor/psy/psysh/src/Psy/Configuration.php:352 (while /var/www/vhosts/domain.com for example is the home directory of the user)

Did a dump of that line : $this->runtimeDir : "/run/user/10004/psysh".

When the isolated environment CageFS is disabled in Cloudlinux, artisan works fine.

[matthew-muscat]

Same issue here...

A dump of the line $this->runtimeDir results in /run/user/0/psysh

The directory structure /run/user/$uid would indicate that it's attempting to access the root user in my environment — which is why it raised the permissions issue.

Speculating here (take this with a grain of salt) I wonder if this has something todo with running tinker as another user previously, with some kind of caching being used resulting in subsequent runs of the process from another user to use the previous /run directory.

[drblue]

Had this for a while on a shared server but thanks to the posts by @ingria and @groovix I looked into it and a workaround (until someone knowledgeable fixes it) is to tell psysh to run in another directory where one has write access.

This can be done through either placing a config-file in ~/.config/psysh/config.php or as .psysh.php in the root of a Laravel-project (ref).

Here's my sample config-file (note that the psysh wiki doesn't mention runtimeDir as a config option but the source code lists it as a valid option):

// Temporary fix for issue #34 in laravel tinker where psysh
// tries to run in `/run/user/<uid>/psysh`.
//
// This overrides that behaviour to `.psysh/` inside the project
return [
    'runtimeDir'    => './.psysh',
];

[franky-ds]

Thanks @drblue , working!

[drblue]

A quick side note: When I added runtimeDir to the config options on the psysh wiki, I noticed that the runtimeDir could be overriden by specifying the environment variable XDG_RUNTIME_DIR. In my case with my shared server, it was set to /run/user/1011, which didn't exist on and nor did my user have the neccessary permissions to create it either.

So I believe this was the culpit at least in my case.

Posted about a suggestion for a fix over at the psysh issue.

[GrahamCampbell]

Please continue discussion over at https://github.com/bobthecow/psysh/issues/443. :)

[fgilio]

This was my error https://github.com/bobthecow/psysh/issues/443#issuecomment-395759749 in case it helps someone

[daviles-jd]

I am a rookie and had the same problem, after giving a few laps I found this solution and I fixed it. The truth still do not understand, I've only run the 2 commands from the console. I hope to help.

How do I install untrusted packages safely? Is it safe to run Composer as superuser or root?# Certain Composer commands, including exec, install, and update allow third party code to execute on your system. This is from its "plugins" and "scripts" features. Plugins and scripts have full access to the user account which runs Composer. For this reason, it is strongly advised to avoid running Composer as super-user/root.

You can disable plugins and scripts during package installation or updates with the following syntax so only Composer's code, and no third party code, will execute:

composer install --no-plugins --no-scripts composer update --no-plugins --no-scripts

The exec command will always run third party code as the user which runs composer.

In some cases, like in CI systems or such where you want to install untrusted dependencies, the safest way to do it is to run the above command.

If later, when opening the homestead. Test in the browser, blank page run "vagrant up--provision" or "homestead up--provision"

[seffparker]

I had to add the prefix <?php at the first line when the new file ~/.config/psysh/config.php is created as per the solution by @drblue

The issue started after upgraded from CentOS 6 to 7. Both are NOT CloudLinux.