I had the same error.
Changing the sshd config to make WP’s root the starting directory of the users SFTP login solved it.
e.g.

Match User wordpress
 ChrootDirectory /home/wordpress/public_html
 ForceCommand internal-sftp

The mentioned settings have not helped to remedy this problem. I doubt they get evaluated when logging in via SFTP. I set just FTP_BASE or both FTP_BASE and FTP_CONTENT_DIR.

This has to be a bug either in this plugin or in core.

I activated debugging, but did not find any entry in the debug log related to this plugin.

• This reply was modified 5 years, 5 months ago by tgoeg.
• This reply was modified 5 years, 5 months ago by tgoeg.

Using define( 'WP_CONTENT_DIR', 'whatever/dir/wp-content' ); finally solved this.

This should definitely be made part of the documentation. I think most people will try to separate users with chroots!

The only thing missing for a proper, secure setup is to make wordpress use a 0027 umask so the files get sane default permissions (using setgid as well).

However, that seems impossible.

A hack is mentioned here (I would not call that a solution):
https://wordpress.org/support/topic/fail-to-make-wp-set-the-umask-i-want/

Then something’s broken inside core.
And define( 'WP_CONTENT_DIR', 'whatever/dir/wp-content' ); made plugins deactivate over night. That’s also pretty ugly.
So I’m still without a solution.

Is my setup possible? I.e. having no write permissions for the apache user (except the upload directory) and having updates work in the backend by using proper credentials/permissions for an SSH user and using this plugin?

Sorry for not being clear enough.
In fact nothing is solved.

The WP install is owned by user:www-data and mode 2750 for directories and 0640 for files.

So user can read and write and www-data can only read.

The group sticky bit makes new files have www-data as owner as well.

I’d like to use this plugin to do the updates via the WP backend so it uses SFTP as “user” to change/write files.

The problem is that after this plugin correctly authenticates the user (I can see 4 successful logins in sshd’s log) the backend says "Update Failed: Unable to locate WordPress content directory (wp-content)." as the original author of this issue states.

If I enable debug logging, nothing relevant shows up in the log, but the fact that there is content in it really is strange, as wp-includes/load.php has the following line:
ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );
So somehow WP_CONTENT_DIR has to be correctly set (and the website works flawlessly apart from updates, which also makes me think the WP_CONTENT_DIR has to be found correctly. In fact it is at its default location.

The only thing probably coming into play here is that “user”‘s SFTP base directory is NOT the web root.

(I need to chroot the user, and the directory to chroot to has to be root owned: http://man.openbsd.org/sshd_config#ChrootDirectory
There is a wwwroot directory in the “user”‘s home which is bind-mounted to /var/www/wordpress)

Reading the documentation I’d assume that setting
define( 'FTP_BASE', '/home/user/wwwroot/' );
should solve this, which it does not.

If I set
define( 'WP_CONTENT_DIR', '/var/www/wordpress/wp-content' );
the updates work flawlessly, but something in this configuration made wordpress deactivate all plugins in the night after setting it without any admin interaction (the page still worked after the updates – maybe this was just a caching issue and the page was actually already broken after the updates; I was not able to reactivate the plugins. Only after unsetting WP_CONTENT_DIR I have been able to reactivate them again.

I am searching for a solution to basically just leave my wp-config and file permissions as they are (which definitely works when using wp-cli for updates, but I need to enable updates in the backend for an external agency). However, SSH SFTP Updater does not seem to work with only touching the FTP_* variables as it seems..

I hope I have been clearer now 🙂

Thanks for your continued help!

I am on php7.2

This could be
https://core.trac.wordpress.org/ticket/41831
or
https://core.trac.wordpress.org/ticket/35517

If so, it should be stated that this plugin is currenty not compatible with php7.x in the given setup.

I’ll see whether some mentioned workarounds fix this.

I seems this is not a bug in this plugin, so no, I cannot demonstrate the malfunction in it.

However, I think users should be made aware that chrooted SFTP setups won’t work on php 7+ . (FWIW, FTP(S) won’t work either).

Do you know of a working setup on php 7+ ? If so, please provide details of the webroot’s file/dir permissions and/or whether it is chrooted.

I think this would have to be some other sort of setup, either with an SFTP server implementation that can chroot to a directory not owned by root (or the directory would need to be writable for group or others, which should be avoided) or simply one that does not chroot (which should be avoided as well).

If I can find a workaround by patching core, I’ll definitely provide info here so others can be spared the troubleshooting.