Chmod(): Operation not permitted vendor/league/flysystem

General
1

When i do: https://dev.mydomain.org/dev/build?flush=all

I get

chmod(): Operation not permitted

GET /dev/build?flush=all

Line 358 in /home/mywebsite/public_html/vendor/league/flysystem/src/Adapter/Local.php

these are the additions to my composer file

“silverstripe/widgets”: “@stable”,
“silverstripe/userforms”: “@stable”,
“silverstripe/gridfieldqueuedexport”: “@stable”,
“sunnysideup/typography”: “@stable”,
“silverstripe/siteconfig”: “@stable”,
“silverstripe/versioned”: “@stable”,
“silverstripers/seo”: “@stable”,
“silverstripe/errorpage”: “@stable”,
“undefinedoffset/sortablegridfield”: “@stable”,
“silverstripe/lumberjack”: “@stable”,
“silverstripe/googlesitemaps”: “@stable”,
“colymba/gridfield-bulk-editing-tools”: “master”

anyone have any ideas what i should try?

2

That’s usually down to file ownership or permissions on the site. The build process does a few things in the file system, so you need to make sure that the webserver owns the files, especially in the public directory (things like .htaccess for example).

It can often happen if you are running commands via the command line as a different user to the webserver process.

3

Thanks

I thought it may be to do with silverstripe-cache deleted everything in there
i thought the permisisons were right because doesn’t it check that when you do /install.php

anyway I traced it to the assets folder and and folder called protected … by printing the path and die()

I removed the .htaccess file and deleted the folder called protected and then did composer update …etc and the .htaccess file and protected folder was recreated.

webserver process ? I’m only ever going to be able to ssh login as my website user .

anyway it seems to have sorted itself out.

1 Like
4

Any other steps for this? I’ve tried deleting the protected folder inside the assetss folder as what sir @surferuk mentioned above, but the error is still there

image
image882×935 42.2 KB

5

Hi,

If you look at the first line of that trace, it shows that the file in question is in the public/assets directory, (not the protected one).

As part of the build process, the webserver changes the permissions on that file. In order to do so, it needs to have ownership rights. Make sure the webserver is able to write to the public/assets directory and either remove the existing htaccess file or change the ownership of it so the webserver can do its thing.

6

It’s not just about permissions here (755 or 777). You should also make the webserver (apache) owner of all files in your public web server folder (where all your SS files are). You can do that with the following command:

sudo chown -R apache /var/www/html/

Since I have virtual hosts (meaning multiple websites enabled) my command would be slightly different:

sudo chown -R apache /var/www/mydomain.com/html

7

Why? The files under public must only be readable by the webserver, and under public/assets must be also writable.

I have the ssh user in the webserver group. The deployment script then allows group writing to the requested folders, e.g.:

chgrp --quiet -R -H www-data public/assets
chmod --quiet -R  g+rwX      public/assets

See the deploy:writable task of my deployer script for details.

1 Like
9

I have the same problem, its been going on for years.

Does anybody have any ideas how to work around it?

My deployment service ssh’s as itself, beanstalk - thats not something i can change
The webserver is www-data - not something i want to change to beanstalk for eg
Beanstalk user is in the www-data group

but if i try running dev/build as beanstalk in the cli (on deployment) or as web user, depending on what the last attempt was, it gives this blasted permissions error.