I'm trying to update both core and some modules via the web interface.

https://example.org/admin/appearance/update

My webhost requires SFTP connection. However, through the Backdrop web interface linked above I only see FTP as a connection option. When I use working credentials in the web update interface, I get an error saying that I can't connect to the FTP server.

Is this likely an issue that the server only accepts SFTP connections and not FTP connections? If that is the case, are there plans afoot to perform web interface updates via SFTP? It would be really handy to be able to just click and button and fill in credentials to perform an update. Thanks in advance.

Most helpful answers

If I got it correctly, nathancraig tried to use the UI ("through the Backdrop web interface linked above"). But depending on the server configuration (at least in Drupal) it can happen that you have to put FTP credentials while updating a module via the user interface.

I guess the solution is to configure the server in a way that you don't need (S)FTP credentials. Here's a short article about it (regarding Drupal):

https://stevenschwenke.de/updatingModulesAndThemesRequiresFTPAccessToYou...

I don't have an answer to your specific question, but have you tried using the Project Installer module to do the updates directly in the UI without needing SFTP credentials? See a demo here (sorry the audio quality is not great):

Comments

Olafski's picture

If I got it correctly, nathancraig tried to use the UI ("through the Backdrop web interface linked above"). But depending on the server configuration (at least in Drupal) it can happen that you have to put FTP credentials while updating a module via the user interface.

I guess the solution is to configure the server in a way that you don't need (S)FTP credentials. Here's a short article about it (regarding Drupal):

https://stevenschwenke.de/updatingModulesAndThemesRequiresFTPAccessToYou...

Thank you for the leads. The first video illustrates what I'm trying to do.

1. Under updates, settings, Manual self-update is checked and saved.

2. When I go to updates modules and select an item or items to update, and proceed to download these updates, I get a continue button asking me to put the site into maintenance mode. Following this, I come to a screen not shown in the youtube link you shared, but one that is shown in the article you linked.

3. From the article, I gather than I must "change the owner of sites/default to the PHP-user (www-data)".

I read the drupal docs linked in your article and searched the page for php. I saw several mentions of the term but nothing on setting the owner of www-data.

I'm confused because the user who owns the directory where backdrop is stored is different from the PHP-user that accesses the database. In other words, the web host doesn't have a means to sign into the server with the PHP-user--they are different logins. I may be misunderstanding things. I thank you for your suggestions, but do you have any further leads or can you explain further what you mean by "change the owner of sites/default to the PHP-user (www-data)". For example, to the best of my knowledge, I don't have a www-data directory.

Olafski's picture

Unfortunately, I can't help much with server configuration questions. As the issue can happen in Drupal as well, and Drupal has more installations in the wild than Backdrop, maybe search the web for something like "drupal update module ftp credentials" and adapt the results to Backdrop.

In one of the first results (https://www.drupal.org/forum/support/post-installation/2011-01-22/module...) the www-data question is explained in different words:

To avoid this, make sure the folder /sites/default is OWNED by the user that executes the drupal scripts. On most Ubuntu installations, this is the apache user: www-data.

So, the user doesn't have to be www-data. The name seems to depend on the operation system. Also, usually (or: out of the box) there is no /sites/default directory in Backdrop.

I guess my answer doesn't help directly, so I hope someone with more server configuration skills can chime in.

This is helpful. I've contacted the admins with the web host. I will report back what I learn. Much appreciated.

themetman's picture

I have been having the same problem updating a couple of modules from the GUI. It used to work fine on my Gentoo System, not asking about FTP, but I have switched to Linux Mint, and now it will not work.

The FTP seems new for some reason (I have just gone to Backdrop 1.18.1). I have enabled the ftp module like so

sudo a2enmod proxy_ftp

But then I get an error:

views_slideshow_cycle2
Error installing / updating
File Transfer failed, reason: /var/www/html/wlg.local/web/modules/views_slideshow_cycle2 is outside of the /var/www/html/wlg.local/web

I have my site outside the web root at /var/www/html/wlg.local/web/

So, how can I overcome this, I think it is looking to download somewhere before overwriting the current module.

I have looked here and here  and here but none of this helps.

By the way, installing new modules works prefectly.

Any ideas?

 

themetman's picture

Thanks @indigoxela I suspect it might be. I have a symlink like this:

/var/www/html -> /home/FG-Docs/public_html/

Then I have the docroot as:

/var/www/html/wlg.local

with the backdrop core in

/var/www/html/wlg.local/web/

I will give it a try with the actual path in a little while and see if that is OK

themetman's picture

That made no difference, @indigoxela, so I will just have to do it manually for now.

themetman's picture

@indigoxela I have sorted it.

As soon as I changed the permissions on the folders to the same as the Apache user, everything worked fine.

Regards

indigoxela's picture

Glad that you sorted things out! Enjoy using Backdrop. :-)

Hi, I have exactly the same problem in linux mint using nginx. Can you please describe how you solved it? What file permissions and ownership did you give to the file structure?

Hi I have exactly the same problem in linux mint using nginx. @themetman can you please describe how you solved it? What file permissions and ownership did you give to the structure?

 

I am getting this FTP server stuff trying to update my local copy to 1.19.1. The docroot is not a symlink, all the file ownership the same as ever, this has worked with prior releases.

 

UPDATE: sorry, the Apache DocumentRoot is set to a symlink. So I guess this is the same bug as ever. I swear I was able to make this work before, though. Maybe not.

 

Now I see on /admin/modules/update this line

"Updating modules, themes, and layouts requires FTP access to your server. See the handbook for other update methods."

Is this new? It won't update directly on the installation, but only download and then upload via FTP? It is literally running on the same computer I am running the browser in, that seems like a peculiar way to do things.

 

indigoxela's picture

Hi brad.bulger,

I don't think, anything changed in Backdrop regarding that.

But if it worked before for you on that computer, but stopped working recently... Did anything change on that computer? Some software updates or setup changes?

There's a core issue for the symlink problem. As you were the one, who provided the pull request, you maybe had that patch applied on your install - that's why it worked, but a recent core update reverted that change...

That's why I'm confused. My patch was in place. But the diversion to the authorize.php page happens before the download takes place, doesn't it? The whole point of it being that it thinks it can't download directly onto the server? I think I've traced this down before.

I've already done the core update directly from a downloaded tarball because it's a security release. Once core is updated and patches applied, contrib module updates work fine.

I have a vague memory of someone having plans to get rid of authorize.php altogether, is that happening?

indigoxela's picture

That's why I'm confused. My patch was in place.

What the... I can understand your confusion.

But unfortunately I can't recommend anything for a solution, as I don't know your system. And even if I did - it seems tricky.

Whenever authorize.php pops up, there's something fishy with file system permissions, or the setup is at least a bit uncommon. I think, that's why people want to get rid of it altogether. However, I don't think this will happen before Backdrop 2.x.