Mr. Bunny's picture

I wrote this post in April 2019 but it got lost somewhere - the problem still persist on core v. 13.3.3

Hi folks! =)

This problem has plagued me for a few months already and I can't seem to find any similar cases anywhere.

An attempt to install any update (core or modules) via Backdrop's own web interface results in error:

- Error installing / updating
- File transfer failed, reason //var/www/example.com/modules/[module name] is outside of the /var/www/example.com

Here's a screenshot:

This error is present on every Backdrop instance I'm managing, regardless of environment. IIRC this error started showing when core updates via web UI were incorporated into Backdrop (v. 1.12.0). 

I've tried:

  • Fixing file permissions -> no effect
  • Updating the core manually (to 1.12.6) and then updating module(s) via web UI -> no results
  • Using different PHP versions (7.1 - 7.3) -> makes no difference

I've also tried installing fresh Backdrop 1.11.4 (last version before enabling core updates), manually installing old version of imagesloaded module, and then trying to update that. This leads to a HTTP 403 error:

Failed to download imagesloaded from https://github.com/backdrop-contrib/imagesloaded/releases/download/1.x-1.0.1/imagesloaded.zip

Core versions 1.12.0 and above download modules correctly but fail to install them.

The (test) server is running Debian 9.8, Apache 2.4.25, MariaDB 10.1.37 & PHP FPM. Apache user & group owns all files, PHP FPM has same users. Apache vhost has the following setup:

DocumentRoot "/var/www/example.com"
ServerName example.com
AllowOverride All #/var/www already has this - no effect here(?)
<Directory "/var/www/example.com">
    allow from all
    Options FollowSymLinks
    Require all granted
</Directory>
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Does anybody have any idea what to try next? =)

Accepted answer

Both of them are untouched aka. have their default values - save database connection info in settings.php.

BUT after digging through practically every server setting I found the reason. It was the trailing slash in PHP FPM setup I had in apache2.conf

<FilesMatch \.php$>
    SetHandler "proxy:unix:/run/php/php7.3-fpm.sock|fcgi://localhost/"
</FilesMatch>

After changing the middle line end to fcgi://localhost (without trailing slash) updates magically started working again.

Now I'm just wondering if something was changed in Backdrop core 11.4 or if I actually started using FPM only then. Nevertheless check your FPM settings if you run into similar problems.

Comments

What do you have in your File System settings? (admin/config/media/file-system)

The double slash looks strange on the error message, not sure if it's related.

Mr. Bunny's picture

File system settings are at their defaults - public path is files (755), temporary path is /tmp (777). I've tried to use tmp (without the leading slash - permissions 750) as temporary folder but it makes no difference.

I'm pretty sure the double slash is the culprit here - although I have no idea how or why. I tried digging around authorize.php to find out what's causing the error bit frankly I don't know Backdrop API well enough to do anything substantial.

What about .htaccess and settings.php? Somewhere it's getting info that the module directory is outside the web root. Somewhere there's a double slash it seems. I haven't seen this particular error before.

 

Mr. Bunny's picture

Both of them are untouched aka. have their default values - save database connection info in settings.php.

BUT after digging through practically every server setting I found the reason. It was the trailing slash in PHP FPM setup I had in apache2.conf

<FilesMatch \.php$>
    SetHandler "proxy:unix:/run/php/php7.3-fpm.sock|fcgi://localhost/"
</FilesMatch>

After changing the middle line end to fcgi://localhost (without trailing slash) updates magically started working again.

Now I'm just wondering if something was changed in Backdrop core 11.4 or if I actually started using FPM only then. Nevertheless check your FPM settings if you run into similar problems.