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

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

Magento 2.2.2
PHP 7.0.28-0ubuntu0.16.04.1

Steps to reproduce

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

Expected result

Check Cron Scripts step runs successfully

Actual result

Check Cron Scripts step fails, reported error is returned
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.

About this issue

Original URL
State: open
Created 6 years ago
Reactions: 6
Comments: 16

Most upvoted comments

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

rouralberto on May 22, 2018

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:

install Magento on a system with web user different than the shell user
remove write permissions for web user for vendor, lib, others per dev docs for two user system
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.

beargroup-jay on Aug 23, 2018

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.

vmsh0 on Aug 22, 2018

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

maryxyan on Jun 18, 2018