As I said in my post above to make life easier (and not install an FTP server) you will need to grant permission to the webserver user to your WordPress install. From the commandline do it like this:

chown -R www-data:www-data /var/www/wordpress

I have just tested it with a clean install of TKL v13.0 WordPress appliance and initially (with no changes) it asks for FTP details. After changing the ownership (as above) it worked fine (WP and all the plugins...)

And it seems that it is not an uncommon problem with WP, although it usually seems to occur on WP on shared hosting. I think your issues are to do with some config somewhere that has come with the backup because it seems that the problem can occur when PHP is upgraded (on shared hosting) and I guess migrating your site to a new TKL version (which has a later version of PHP included) is in effect a similar thing.

From my reading there are a few possible resolutions but as a non-WP user, I'm not really sure what the best way to go would be, perhaps first thing is to check your php.ini file (something like /etc/php/apache2/php.ini IIRC) and make sure that the line "allow_url_fopen = on;" exists and is not commented out. If you change that I think you'll need to restart the webserver (service apache2 restart IIRC).

If that's a no go, then I suggest you do a bit of googling yourself and see what you can find. Worst case scenario you could even try posting on the WP suppot forums. Keep in mind that TKL v13 is based on Debian Wheezy (and TKL v12.x was based on Debian Squeeze). If you get lost I'm happy to try to help you (if I can) but it'd be great if you could post the links/instructions that you are struggling with..

Also if you find a resolution, if you could post back that'd be great, as other TKL users may well find themselves in the same situation and be looking for a fix. Thanks

How about trying just restoring the database and /var/www/wordpress folder to a clean instance and see how that goes... That's what I'd do before I decided to just do it all manually...

But to clarify; technically this is not a bug, but a security feature. With the permissions set as they are, even if your webserver (or WordPress itself) is compromised, a remote attacker can not maliciously alter the WordPress install itself. So it was set like this by intention. Security is often a trade off against user-friendliness. Seeing as WordPress is so popular it is often targeted and so it seemed like a reasonable position to take. FWIW the TKL WP has been setup like this since it's first release in 2009.

Having said that, TurnKey's popularity has grown and considering the number of frustrated users we have decided to change the default setting. This does reduce the level of security, but we figure that the trade-off of less frustrated users (like you) wasting their time it is a fair trade-off to make. As such, you'll be pleased to hear that as of the next TKL release (v13.1 - currently being worked on) this default has been changed to accommodate an easier in-place WP upgrade.

To address your individual points:

1) As has been mentioned there is a simple workaround above. Although the workaround posted on the TKL tracker on GitHub (here) is probably preferable.

2) The firewall has port 22 open already and SFTP is enabled (and listening on it). Port 22 is the default SFTP port (port 20 is default FTP port and 21 is default FTPS port - note FTPS is different to SFTP).

3) With the adjustments noted in point 1 (above) there is no need for an additional FTP/FTPS server. As we try to make the TKL servers as lean and light weight as possible we do not include anything more than what is required.

So I'm really sorry to hear that you wasted 5 hours on this, but I hope that you can understand where we come from and as I say, the default config will be adjusted to make it easier in the future.

And thanks for persevering and using TurnKey. Hopefully your ride is easier from here on in.

TBH I didn't realise that updating via SFTP was an option - only FTP or FTPS (you probably know already but for other casual readers: SFTP is SSH tunneled FTP; FTPS is FTP over SSL). You post prompted me to do a little investigation and I found this plugin. Is that what you tried to use to update via SFTP?

Also in response to your post; personally I think that statement "the release was dead in the water" is overly harsh. There are thousands of TurnKey WordPress sites running currently and the number of complaints is only a very small fraction of that. Perhaps for your purposes/usage scenario that may be the case but I don't think that it is fair to portray it as the blanket reality.

Having said that, I have acknowledged, the current config is definitely not optimal (we consider it a bug). I also acknowledge that the permissions posted within this thread are also sub-optimal. But you'll notice that in a couple of posts I have referenced the bug on the GitHub TurnKey Issue Tracker (here it is again). You'll note that that there it details the specific permissions required (i.e the wp-content directory) rather than taking ownership of the whole /var/www/wordpress tree.

I know that it is still not optimal security wise, but I thought that it was a reasonable balance. If you have or know of an even better permission/ownership config (or any other WP config for that matter) then please work with us and let us know ASAP as the change listed there (on GitHub) has been applied to the appliance source and will be included in the upcoming release. If it can be done better we'd like to know so we can make the new release the best balance between usability and security.

Perhaps we should revert the permission changes and include the SFTP update plugin and leave the WP directory tree owned by root? That might be preferable to the changes that I made to permissions?

FWIW the code that builds the WP appliance (with TKLDev) is on GitHub here. The script that specifically does most of the heavy lifting (i.e. install & config inc setting permissions) is here.

I'm not quite sure what you mean by "You've also no automated process that allows TKLBAM to restore a destroyed or inop appliance.". Are you suggesting that there should be a way to automatically restore a backup on launch of a new appliance?

Assuming you are, FWIW If you are hosting on AWS via the TurnKey Hub you can launch a new appliance with your TKLBAM backup pre-integrated (it restores your backup after installing and applying security updates). Although it would be quite cool if there were an inithook that asks if you want to restore a backup (after you've added your Hub API key) on firstboot of a fresh appliance. Is that what you meant? If so I think that's an awesome idea! In fact I've added it as a 'feature request'.

TBH I'm surprised that the earlier versions didn't have this same issue because AFAIK the build code was the same for previous versions, just this one includes a newer version of WP off the bat.

Also I just wanted to say that I'm sorry if I seem (or did seem in my previous posts) ungrateful for your feedback. I guess I can be a little defensive of TKL because I have put so much of myself into it (although FWIW I work for TurnKey now - apologies on the shameless self promotion) that sometimes I react out of defensiveness when I feel like someone is giving unfairly harsh criticism. But I can safely say that I speak for all of us here at TurnKey that TKL really does appreciate feedback and (constructive) criticism even if we don't always have the resources to implement it straight away.

So I again apologise that you have found it so painful and that you wasted your time trying to get it to work the way you wanted.

But let's work together to make TurnKey the best! After all that is the superpower of free open source! Users such as yourself that have skills and knowledge, can contribute back to make each new release so much better than the one before.

You'll need to endure a paragraph or too of 'discussion'! :)

Because the only way to make it really easy is to reduce the level of security for your whole server. Obviously that has implications so we don't want you doing that unless you know what the potential costs are. The flipside is that without updates WordPress itself is likely to become vulnerable (although the chance of the attacker being able to take over your whole OS is highly unlikely due to the choices we have made). So we try to find a middle line...

To allow upgrade of plugins and themes you can follow the instruction here. However that still won't allow major updates. To ensure that the system uses the 'direct download' method make sure that you adjust the wp-config.php file (as included on GitHub). To allow WP upgrades to complete you will need to allow the webserver account to own the whole WordPress directory tree; like this:

chown -R www-data:www-data /var/www/wordpress

After the update has completed I suggest that you change ownership back; like this (it should still allow you to install and upgrade plugins and themes but not major updates to WP itself).

chown -R root:root /var/www/wordpress
chown -R www-data:www-data /var/www/wordpress/wp-content

I have been meaning to comment on this post, plus more importantly add it to the 'list of many ways to work with your TKL server' doc (aka "How to admin and/or edit/upload files to TKL appliances"). Finally got there...!

I do think though that the doc page needs a much catcher title! :)

Hi Frank,

My apologies. I did read your post but somehow missed that you had already tried this. I'll claim a senior's moment :-)

I just did an AWS install of the v14 WordPress appliance, ran into this WordPress 4.4 upgrade problem, changed the owner to www-data:www-data from the Wordpress folder down including the WordPress folder, changed the folders to 755 and the files to 644....and the WordPress 4.4 upgrade went through without a problem.

Can you double-check the following:

- WordPress folder is set to www-data:www-data and not just its children

- Run the following commands at the www level to ensure consistent permissions

sudo find . -type f -exec chmod 644 {} \;

sudo find . -type d -exec chmod 755 {} \;

Glad you got it working Frank. I had noticed when I was looking through some of the files in the default WordPress VM that at least one of the folder settings was 2775 which I have never seen before. Something to look into at some point. But, for now, we have success :-)