Error from Updater Application Cron Script: Found non-writable path(s)

[vmsh0]

When installing an extension, updating Magento or running the update cron jobs, the following error is returned:

Error from Updater Application Cron Script:

Found non-writable path(s):
[list of all Magento2 files]

Preconditions

1. Magento 2.2.2
2. PHP 7.0.28-0ubuntu0.16.04.1

Steps to reproduce

1. Confirm apache2 user with ps aux | grep apache2 (for me: www-data)
2. Reapply permissions in Magento2 root folder
   # find . -type d -exec chmod 775 {} \;
# find . -type f -exec chmod 664 {} \;
# chown -R www-data:www-data .
3. Verify permissions have been correctly applied e.g. with ls -la
4. Flush Magento cache
5. Run the Readiness Check for any extension

Expected result

1. Check Cron Scripts step runs successfully

Actual result

1. Check Cron Scripts step fails, reported error is returned
2. var/log/update.log is several GBs big reporting the error again and again

Please note that for the sake of experimentation I also tried to apply 777 permissions to all files and folders (this is not in production) and it still returns the same error.

[ywsw]

I am having this exact same issue with trying to upgrade 2.2.3 to 2.2.4

[maryxyan]

Same thing 2.2.2
Eddit -permission problems solved by using root making www-data the owner and giving 775 to folders and files.

[rouralberto]

Same here, reporting "Found non-writable path(s):" and listing files that doesn't even exist.

[anthr76]

Having the same issue

[ywsw]

Solved:
I ran the commands find . -type d -exec chmod 775 {} \; and find . -type f -exec chmod 664 {} \; and then chown -R www-data:www-data . all as SUDO and then flushed the cache and most of the readiness checks were solved except for three supposed .sample files in the main directory which did not even exist. I created these files and ran the codes above again and now the readiness check works

[beargroup-jay]

Also having this issue on a 2.2.5 site, var/log/update.log growing very quickly with these "errors".

However, per the devdocs:

When you’re ready to deploy your site to production, you should remove write access from files in the following directories for improved security:

vendor
app/code
app/etc
lib
pub/static
Any other static resources
generated/code
generated/metadata
var/view_preprocessed

In accordance with this, and our own security practices we are using a split ownership scheme where the web user can only write to a handful of specific directories, and don't want the Magento web user to be able to write to most of the directories listed.

Hi @vmsh0 i'm not able to reproduce by following steps your described, Also did you try to set permission by devDocs -> https://devdocs.magento.com/guides/v2.2/config-guide/prod/prod_file-sys-perms.html

[vmsh0]

Hi @engcom-backlog-nazar,
Thank you for your response.

I don't want to sound harsh but I clearly described all the steps I've taken, which include setting the filesystem permissions, in my original post.

This has happened throughout different versions of the software to many people, so maybe it's time to revise the specs and the code.
For one, it seems absurd that you have a system in place where one has to keep the sample configuration files in the root directory, and to have them writable, to even be able to run the software without getting multiple GBs of log files. :)

I'm afraid I cannot offer further help to reproduce the issue as I'm no longer using Magento.

All the best.

[beargroup-jay]

For us this was triggered by the "update" cron, which afaik is responsible for applying updates to Magento itself via the System Upgrade feature in admin. This is incompatible with the recommended hardening steps of removing write access, we do not ever want to apply updates through admin so we removed the "update/cron.php" from our crontab.

As far as steps to reproduce this issue, rough outline of what we had done to see it was:

1. install Magento on a system with web user different than the shell user
2. remove write permissions for web user for vendor, lib, others per dev docs for two user system
3. run the update/cron.php file, which will perform a readiness check

Ultimately, since we never want code updated via the admin interface, removing the cron job is a win/win for us. However, if the readiness check is triggered elsewhere that could remain problematic.