.htaccess permissions error when trying to Update

Self-Hosted | v5
#1

Good morning all.

I got a notification this morning that v5.2.17 is available to upgrade from v5.2.16. When I try run the update, I get the following error that my .htaccess file is not writable.

[2021-08-07 17:03:49] production.ERROR: Cannot update system because .htaccess is not writable {“userId”:2,“exception”:"[object] (App\Exceptions\FilePermissionsFailure(code: 0): Cannot update system because .htaccess is not writable at /var/www/clients/client4/web5/accounts/app/Http/Controllers/SelfUpdateController.php:104)

I have an .htaccess file in the web root folder, as well as one in the public folder. They are 644 and 755 respectively. I have changed these files to 666 and 777 respectively, but the update is still failing with the same error in the log.

Is there another .htaccess file that I’m missing, which is the one that’s trying to be updated?

Chris

#2

@david any thoughts?

#3

@david Hi David, sorry to poke you again on this. Any suggestions on where I might look for this?

Chris

#4

Does the web user own the .htaccess file thou? There is one in the root of the project and one in the public folder

#5

@david Yes, both .htaccess files have the correct owner/group setup on them.

Chris

#6

You may want to try the upgrade again. The system does a recursive file check to ensure every file is writable by the webuser. If this passes the upgrade proceeds.

#7

I tried the upgrade again, to no avail, however I’m getting the following error now (which I think is the real issue).

[2021-08-11 19:46:02] production.ERROR: SplFileInfo::isFile(): open_basedir restriction in effect. File(/var/www/clients/clientX/webX/accounts/…) is not within the allowed path(s): (/var/www/clients/clientX/webX/accounts:/var/www/clients/clientX/webX/private:/var/www/clients/clientX/webX/tmp:/var/www/accounts.XXXXXX.XXX/accounts:/srv/www/accounts.XXXXXX.XXX/accounts:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin:/dev/random:/dev/urandom) {“userId”:2,“exception”:"[object] (RuntimeException(code: 0): SplFileInfo::isFile(): open_basedir restriction in effect. File(/var/www/clients/clientX/webX/accounts/…) is not within the allowed path(s): (/var/www/clients/clientX/webX/accounts:/var/www/clients/clientX/webX/private:/var/www/clients/clientX/webX/tmp:/var/www/accounts.inoventive.ca/accounts:/srv/www/accounts.XXXXXX.XX/accounts:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin:/dev/random:/dev/urandom) at /var/www/clients/clientX/webX/accounts/vendor/codedge/laravel-selfupdater/src/helpers.php:36)

I’m not 100% sure on how to modify the directive to give InvoiceNinja what it’s looking for though.

#8

Maybe this will help: https://stackoverflow.com/a/34980645/497368

#9

The app downloads the .zip file and puts it in the system /tmp dir

Your host has disabled access to /tmp

#10

Here is part of the open_basedir directive setup in ISPConfig. Am I interpreting this wrong in that since /tmp is listed, it should be accessible?

image
image2388×1667 304 KB

#11

So from my understanding if you have an openbase_dir for :/tmp for the executing version of PHP it should work.

#12

I can see that the update was downloaded to the /tmp folder, so permissions look ok so far. It’s got to be something after this step.

image
image1217×885 99.5 KB

#13

i had about three errors pop up going from 5.2.5 to 5.2.17. the problem was the error was only visible for a split second and i had to record my screen and play it back and pause it to read the error.

#14

Yeah, I’ve seen that. It’s been a mix of the .htaccess error, open_basedir error and then a generic Server Error.

Is there a manual update procedure I can follow in the meantime?

#15

on a debian system i just had to run

apt-get update
apt-get upgrade

and

chown -R www-data:www-data /usr/share/nginx/invoiceninja

then the update went through fine. as far as i can tell, this was with no data imported.

#16

@christopher.phillips

Ok, that screenshot of /tmp is helpful. The updater works like this:

  1. Filesystem check for permissions
  2. Download .zip
  3. Unpack.
  4. Overwrite files from /tmp to your installation
  5. Perform Migration
  6. Optimize files
  7. Composer install

It looks like everything is completing except for that last step which uses exec() to run composer.

To test this is the failure point, if you can drop to the cli and run

sudo -u www-data composer install -o --no-dev

swap www-data with your webuser

After that, attempt to login.

#17

Am I to run that command from the /tmp location where the update was downloaded, or from the original install folder?

#18

@christopher.phillips

run that command from your original installation folder.

#19

That specific user does not have sudo privileges, however I can run the command as the local web user. Here is the output.

image
image1134×733 161 KB

#20

Does the app work now?

sudo -u www-data

Will only run the command as that user, it shouldn’t elevate their access to super user