Docker: chown WordPress install to web user so wp-admin updates work#49110
Docker: chown WordPress install to web user so wp-admin updates work#49110DevinWalker wants to merge 1 commit into
Conversation
tools/docker/bin/run.sh runs as root during container init (wp core download, wp config set, plugin symlinks all execute as root), but Apache subsequently runs as www-data. Without a chown step, every file under /var/www/html stays root-owned and the WordPress auto-updater fails with "files_not_writable" — surfacing the "An automated WordPress update has failed to complete" admin notice and blocking plugin, theme, and core updates from wp-admin. Add an unconditional chown -R "$user:$group" /var/www/html just before Apache starts. Running on every container start (not just first install) means existing environments provisioned before this fix self-heal on the next `jetpack docker up`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
tbradsha
left a comment
There was a problem hiding this comment.
While I suspect this shouldn't cause any issues...
I haven't yet checked out your branch, and everything is root:root on my end, but I'm not able to reproduce the reported issue; updates to plugins/themes work fine for me. Do you have more context on the failing setup?
As for updating core, I can confirm it also worked for me. That said, I recommend instead using jetpack docker update-core (which runs tools/docker/bin/update-core.sh in the env), as otherwise tests that run on Docker risk having mismatched core PHPUnit tests, which have been known to break things.
cc: @anomiex in case I missed some nuance here.
Fixes MONOREP-406
Proposed changes
chown -R "$user:$group" /var/www/htmltotools/docker/bin/run.shjust before Apache starts.run.sh(wp core download,wp config set, the plugin symlinks loop, etc.) all run as root, but Apache subsequently runs as www-data. Without a chown step, the WordPress install stays owned byroot:rootand the auto-updater fails withfiles_not_writable. From the user's side this shows up as:An automated WordPress update has failed to complete - please attempt the update again now.admin notice.wp core updatesucceeding only when run as root viadocker exec -u root, never via the normal admin flow.jetpack docker up— no manualchownrequired by anyone hitting this today.Related product discussion/links
7.0-beta2-61800because nothing could overwrite the existing files. Setup workflow referenced: PCYsg-GJ2-p2.jetpack docker update-corewas announced on +jetpackdevelopment in Feb 2025 but is still undocumented intools/docker/README.md— separate doc PR could follow.Does this pull request change what data or activity we track or use?
No — local dev environment script only.
Testing instructions
jetpack docker clean && jetpack docker up -d(or justjetpack docker down && jetpack docker up -dagainst an existing install that's currently broken).www-data:www-data(previously:root:root).wp-admin. If a previously-installed environment had been showing "An automated WordPress update has failed to complete - please attempt the update again now", that notice should be gone (or clear after the next update check).jetpack docker wp core update). It should succeed instead offiles_not_writable.jetpack docker wp plugin update --allandjetpack docker wp theme update --all.ls -la tools/docker/wordpress/wp-includes/version.php— Docker Desktop's user namespacing should still present the file as readable from the host.