You are here
David Schieber - Tue, 2016/03/29 - 00:32
I have a new Wordpress appliance install and not very familiar with Linux or Wordpress. I need to unzip some files on the server via PHP. I get this error returned.
Error #224834. This directory, `/var/www/wordpress/`, is not write enabled according to the server. Please verify proper write permissions to continue. If this persists, contact your web hosting provider and tell them that is_writable("/var/www/wordpress/") returns FALSE in PHP.
Presumably I need to change owner of that folder so that root can write to it? I can't figure out how to do that.
Thanks for your help!
Forum:
Tags:
Root should be able to write to it already
As for changing ownership and working with permissions there are 2 main commands: chown (change owner) and chmod (change mode). Both of them are standard nix commands so are well documented online. FWIW when using Linux you can usually get help for a command by using the '--help' switch; or extensive info by reading the manual i.e. 'man' command; e.g. 'man chmod'.
To change ownership:
or to change a directory and all its contents use the -R (recursive) switch:chmod works sort of similarly but uses a (generally) 3 digit number to represent levels of permissions to user|group|everybody. The numbers are read=4; write=2; execute=1. Then you just add them up to get a number between 0 (no permissions at all) to 7 (read, write and execute). So to allow the user full permissions, the group read/write and everybody else read only you would do this:
If you want more info I suggest you have a goolge. Others probably explain it better than me...
Also keep in mind that TurnKey is Debian based, so almost everything that applies to Debian also applies to TurnKey.
Change ownership
Thanks Jeremy. I did end up changing the permissions on the wordpress directory. The wordpress directory had "nobody/nogroup" for owner/group.
> cd www
> ls -al
total 12
drwxrwxrwx 3 root root 4096 Sep 3 2015 .
drwxr-xr-x 13 root root 4096 Sep 3 2015 ..
drwxr-xr-x 5 nobody nogroup 4096 Mar 28 09:22 wordpress
I resolved the problem in this way.
> chown root:root wordpress
> ls -al
total 12
drwxrwxrwx 3 root root 4096 Sep 3 2015 .
drwxr-xr-x 13 root root 4096 Sep 3 2015 ..
drwxr-xr-x 5 root root 4096 Mar 28 09:22 wordpress
Incidentally, I miss-spoke when I said "I get this error". I'm actually the host administrator and it was a wordpress developer who had the error and I don't know if they were working from a command line or a web application. The developer was logged in as root.
FYI ...
> cd wordpress
> ls -al
total 184
drwxr-xr-x 5 root root 4096 Mar 28 09:22 .
drwxrwxrwx 3 root root 4096 Sep 3 2015 ..
-rw-r--r-- 1 nobody nogroup 418 Mar 19 20:21 index.php
-rw-r--r-- 1 nobody nogroup 19930 Mar 19 20:21 license.txt
-rw-r--r-- 1 nobody nogroup 7360 Mar 19 20:21 readme.html
-rw-r--r-- 1 nobody nogroup 5035 Mar 19 20:21 wp-activate.php
drwxr-xr-x 9 root root 4096 Mar 19 20:14 wp-admin
-rw-r--r-- 1 nobody nogroup 271 Mar 19 20:21 wp-blog-header.php
-rw-r--r-- 1 nobody nogroup 1369 Mar 19 20:21 wp-comments-post.php
-rw-r--r-- 1 nobody nogroup 2853 Mar 19 20:21 wp-config-sample.php
-rw-r--r-- 1 root www-data 1569 Mar 6 12:17 wp-config.php
drwxr-xr-x 5 www-data www-data 4096 Mar 6 12:56 wp-content
-rw-r--r-- 1 nobody nogroup 3286 Mar 19 20:21 wp-cron.php
drwxr-xr-x 16 root root 4096 Mar 19 20:15 wp-includes
-rw-r--r-- 1 nobody nogroup 2380 Mar 19 20:21 wp-links-opml.php
-rw-r--r-- 1 nobody nogroup 3316 Mar 19 20:21 wp-load.php
-rw-r--r-- 1 nobody nogroup 33770 Mar 19 20:21 wp-login.php
-rw-r--r-- 1 nobody nogroup 7887 Mar 19 20:21 wp-mail.php
-rw-r--r-- 1 nobody nogroup 13021 Mar 19 20:21 wp-settings.php
-rw-r--r-- 1 nobody nogroup 28594 Mar 19 20:21 wp-signup.php
-rw-r--r-- 1 nobody nogroup 4035 Mar 19 20:21 wp-trackback.php
-rw-r--r-- 1 nobody nogroup 3061 Mar 19 20:21 xmlrpc.php
What do you think of that change? Why is it set that way by default and should I return it to nobody/nogroup? How is that done if I wanted to do that?
Thanks again.
David
Changes look fine...
1. You can own (almost) everything with either root:root or nobody:nogroup and then the webserver will generally only have read only access. Whilst root and nobody are very different users, for all intents in this sort of scenario the effect is essentially the same so long as the files/directories aren't owned by the webserver account (www-data). It shouldn't stop things like posting content, as that is generally stored in a database. It may however stop you from uploading files, adjusting settings from within WordPress and doing other stuff like installing plugins and themes. It can be (legitimately IMO) argued that this is much more secure as if the software gets compromised only whatever can be changed/controlled by the webserver can be touched. E.g. under this circumstance malicious files could not be included in the system or core WordPress files could not be replaced with malicious copies.
2. You can allow the whole structure to be owned by www-data. That will allow you to tweak any WordPress config via the web admin page and you can install and update WordPress and it's plugins and themes really easily. It also means that if WordPress is vulnerable, then an attacker could infiltrate your system and change any of your settings and replace any WordPress file with a malicious copy.
3. I know I said 2 paths above; but you can take a middle ground and have some areas owned by root/nobody and others owned by www-admin.
FWIW originally TurnKey used the 1st model. Over time it adapted the 3rd way and for the new/next release we will essentially be going with the 2nd option. Users having issues updating WordPress is the main driving factor for us to choose the 2nd option. Whilst I still think that essentially the 1st path (with perhaps some tweaks) is the best, most secure way to go; the unfortunately reality is that it is then tricky for some users to update WordPress. If WordPress is not updated then it becomes insecure as exploits become known. This means that whilst the server itself should essentially remain secure; the WordPress running on top of it can be exploited and perhaps even distribute malware. So we have decided that we need to sacrifice a "best practice" security model to allow users to easily update their WordPress install. This means that users will be able to click "update" within the admin area and update WordPress. Sorry a bit of a rant, but I wanted to give you all the info.
Having said all that, hopefully you can make up your own mind on the best way to go. Whether you'd like a really secure, locked down; although not so user friendly WordPress. Or whether you want it to be really easy to administer using the Web UI, easy to update and install new plugins and themes, but potentially be more open to zero day type exploits...
Try uploading to /var/tmp
When you have permissions challenges when ftping a folder to your WordPress directory you can usually ftp it to your /var/tmp directory and then use your Webmin File Manager to move the directory to the desired location. Remember to set the directory and file permissions to the recommended WordPress settings (755 and 644 respectively).
Cheers,
Tim (Managing Director - OnePressTech)
Different scenario / same problem
I'm sorry to bring up such an old post, but I have a very close issue, and looking for a solution I ended up here, so maybe it's a good idea to keep useful pieces of information in the same spot.
I have a freshly installed turnkey linux wordpress appliace on proxmox, and I can confirm you went the 2nd way, as everything is owned by www-data:www-data. Nonetheless, Wordpress plugins claim they can't write into files (.htaccess, wp-config.php) and even ftp users can connect, download but not overwrite files in /var/www/wordpress.
I would love any hint as after two days into this I'm completely lost. Permissions look good, with all folders 775 and files 644.
Cheers.
Hmm, weird. I can't reproduce?
FWIW I just installed the v17.1 TKL WordPress template (downloaded via the Proxmox UI) to a new LXC container on Proxmox v7.1. After launching via the Proxmox UI, I logged into the WP container via SSH and ran through the firstboot scripts. Then I opened my browser and logged into WP webUI as 'admin' and did all available updates (WordPress itself plus the anti-spam module and the 3 default included themes). It all "just works" for me?!
Perhaps I'm missing something and there is a specific plugin and/or process that causes this issue? If so, please describe how you get to this situation (assuming it's reproducible).
Having said that, it seems to me that if www-data (recursively) owns /var/www/wordpress ('chown -R www-data:www-data /var/www/wordpress') and all dirs are 755 ('find /var/www/wordpress -type d -exec chmod 755 {} \;') & files 644 ('find /var/www/wordpress -type f -exec chmod 644 {} \;'), then I don't see any good reason why it shouldn't work!?
If you're hitting this right from the start though, then I suspect it's nothing to do with TurnKey. I'd be exploring issues on the Proxmox host. Are any other containers behaving weirdly? Have you got enough free space? Has the storage device experienced issues and auto-remounted the volume read only?
Hi Jeremy and thank you for
Hi Jeremy and thank you for your prompt reply.
You are right, it appears to affect only one specific plugin (Really Simple SSL).
After further investigation (wierdly) it was able to write on .htaccess, but prompted the error of not being able to write on wp-config.php.
I deactivated it and handled SSL configuration on my own.
All other functions run smooth, as upgrades, themes and plugin installations etc (they actually always did as the plugin itself was installed by wordpress...)
Kind regards
Add new comment