Update to 5.7.57 gives errors


I’ve been searching the forum for a couple of hours and tried numerous suggestions from others and have been unable to find a solution.

I have not updated since about August and decided to do so today. Normally I do this via the command line; however, today I attempted to update via the web UI and saw the error that I could not write to the .env file. After a brief search, I discovered that it had incorrect permissions. After correcting the permissions, I again attempted the update via the web UI and that’s where it all went down hill.

Momentarily, I saw a gray screen with the flashing ellipsis, but then the screen remained gray. I searched a little more and couldn’t find anything. I followed this by updating the zip file via command line the way I have successfully done in the past. Temporarily, this then displayed an invoiceninja page with a 500 error.

I followed this with composer install and artisan optimize. Usually, that’s all that has been needed and I can log back in without issues.

For what it’s worth, I do not have any apache error logs and the access logs are irrelevant (from what I can tell). The most recent items in the invoice ninja error logs was from September and seemed unrelated to this.

Given that none of this fixed my situation, I attempted to reinstall invoice ninja the way I originally had done via the zip file from GitHub and just reused all of the data from my original .env file and original database. Unfortunately, I’m still in the same position with the gray screen displayed via web UI. When I attempt to login via the mobile app, all I get is a 500 error. I do have my .env file and mariadb database backed up.

I use this for my business and has worked brilliantly, until today. Any tips or advice is greatly appreciated.

OS: Ubuntu 22.04 (direct install via zip files)

I am happy to provide any additional information that may be helpful. Do note that due to reinstalling, the original invoice ninja log files are gone.


If you’re seeing a 500 error the details will be logged to either storage/logs or the web server error log, having the error details will help determine the problem.

It may help to run php artisan migrate.

Thank you for the quick response. Not to be rude, but that reply feels very similar to a copied and pasted reply I’ve seen in many other posts without actually having read what I wrote in the OP.

Unfortunately, php artisan migrate returned INFO Nothing to migrate.

As noted in my OP, because I attempted to reinstall, there are no logs to be found in storage/logs.

All of the logs are too long to post here.

/var/log/apache2/invoice-ninja.error.log is an empty document.

/var/log/apache2/invoice-ninja.error.log.1 is dated from back in April.

The only logs with today’s date are the access logs:


The only way for us to help with a 500 error is to have the details.

If you see a 500 error in the app the details will be logged on the server. Another option is to set APP_DEBUG to true in the .env file but we don’t recommend it if the app is publicly facing.

So I installed invoice ninja and a new VM and setup and initial login went fine.

Next, I tried to migrate my previous mariadb database and the public/storage directories to the new installation. Thankfully, I still got the web UI login page without any issues. However, when I attempted to login at the web UI, I got the following:

My nginx error log only shows the following:

2023/12/07 00:15:08 [notice] 14777#14777: using inherited sockets from "6;7;"
2023/12/07 01:02:56 [notice] 17586#17586: signal process started

Invoice ninja error log is blank.

Would it help to see the invoiceninja.access.log? Or is that irrelevant?

Apologies for the ignorant question, but, If i set APP_DEBUG="true", where do I find the logs?

Thanks again.

The access log isn’t helpful.

When APP_DEBUG is set to true the Laravel errors are shown on screen, if the error is in the Flutter app you won’t see the error though.


After setting APP_DEBUG="true" it now shows 500 No Company Found.

Maybe I restored the backup incorrectly?

I took a backup of the original mariadb database similar to the following:
sudo mysqldump -u root invoiceninja > invoiceninja.sql

After creating a new DB on the new VM, I transferred that dump from the old VM to the new VM and restored it with the following:
mysql -u root -p invoiceninja < invoiceninja.sql

On the old VM, I also backed up the web files:
sudo tar -cpzvf invoiceninaja.tar.gz /var/www/invoiceninja/

Per something I found on the forum, I only restored the public/storage folder on the new VM.

Could that be causing the issue? Should I have restored everything in my web files backup?

Any other suggestions for restoring the backup from my previous?

@david can you please advise?

Okay, I’m not sure what happened here. Whilst I was awaiting another response here, I decided that I’ve tried everything else, why not remove my /var/www/invoiceninja directory and replace it with everything from my archive from the old VM (including updating permissions on the new VM). I followed that with artisan optimize, refreshed my browser…

…and everything has been restored!! Albeit, on the new VM (which is irrelevant).

So, my question is, what went wrong when I performed the update a couple of days ago? Any thoughts or suggestions? Are there any recommended best practices for updating an installation from the zip file?

@hillel Thanks for your assistance thus far.

Edit: Later in the day I saw the little triangle notifying me there was an update. I backed everything up again a tried updating from the web UI. This time was successful and did not present the grey screen of death nor any 500 errors. Still don’t quite understand what happened though.