If you're experiencing issues with your self-hosted Invoice Ninja instance, follow these general troubleshooting steps before diving into the specific sections:
storage/logs directory.After making any changes to your cron setup you'll want to force a recheck of the cron setting. To do this navigate to http://url/update?secret=
If you are faced with your recurring invoices not firing, or your reminders not sending, then most likely your cron job isn't working. The first thing is to make sure you have your cron jobs configured correctly by following the guide here
If you are using shared hosting, then will need to add an additional parameter to the cron command which looks like this:
cd /path/to/root/folder && /usr/bin/php -d register_argc_argv=On artisan schedule:run >> /dev/null 2>&1
Please note that on some systems the php location may be different, so confirm with your hosting provider which path to PHP you need to use.
To test your changes, navigate your browser to the update URL which is in the following format:
https://yourdomain.com/update?secret=
The secret variable is located in your .env file until the key UPDATE_SECRET , this will force a recheck and if the cron is working the red error triangle will disappear.
If you are using Cloudflare, then most likely Cloudflare could be caching your static data. To force cache busting, edit your nginx.conf file and add in the following snippet
location ~* \.pdf$ {
add_header Cache-Control no-store;
}
On Apache based servers, open the /public/.htaccess file and update the mod_headers block
<IfModule mod_headers.c>
# Blocks Search Engine Indexing
Header set X-Robots-Tag "noindex, nofollow"
# Prevents PDF File Caching
<FilesMatch ".pdf$">
Header set Cache-Control no-store
</FilesMatch>
</IfModule>
If you are using gmail smtp relay, then a additional .env variable is required.
For Gmail SMTP Relay also ensure you have configure this service in Google by using the following steps:
Go to [Apps > Google Workspace > Gmail > Routing]
Next to SMTP relay service, click Configure.
Set up the SMTP relay service by following the steps in [SMTP relay: Route outgoing non-Gmail messages through Google]
Then, in your env file, use the following:
Gmail SMTP Relay requires a proper EHLO hostname domain to be sent during the SMTP handshake: [127.0.0.1] doesn’t cut it anymore. For that, Laravel has to check for a host domain variable and send it along with the handshake request.
MAIL_EHLO_DOMAIN="server.domain.com"
MAIL_MAILER=smtp
MAIL_HOST=smtp-relay.gmail.com
MAIL_PORT=587
MAIL_USERNAME=xxxx
MAIL_PASSWORD=xxxx
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=xxxx
MAIL_FROM_NAME=xxxx
You will also want to make sure you do not have any firewall rules which may be blocking access to the Google servers, just in case, ensure the following IP addresses are whitelisted:
142.251.163.28
172.253.63.28
172.253.118.28
74.125.24.28
142.250.114.28
142.250.4.28
142.251.12.28
172.217.194.28
142.250.31.28
142.251.167.28
172.253.115.28
For more detailed information on Gmail Relay, see this post of our forum by community member charles
https://forum.invoiceninja.com/t/emails-not-sending-yet-another-thread-v5-5-55/12401/9
The MAIL_MAILER field defines which email driver you wish to use, this could be postmark, mailgun, smtp, log - anything that Laravel 9 supports natively is supported in this app.
If the mail config is correct, the next place to check would be to check the error logs for any errors that are being thrown, the error log is found in storage/logs/laravel.log
The final source of information in diagnosing mail troubles is to inspect the System Logs tab in the dashboard of the application, in here we log any messages from the mail server itself which may be instructive as to the cause of your issues.
If you are using the Queue system ie. QUEUE_CONNECTION=database then you may also want to check the jobs table in the database, there should be no records in that table... If there are records in the table it means that your queue is not running and therefore no mail jobs are being processed.
It's possible the emails are sent but are blocked for DNS, SPF, DKIM or other reasons. In these cases emailing a test invoice to mail-tester.com can help debug certain problems.
Also, if you see in /storage/logs/invoiceninja.log this line error failed with stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed then try running yum update on your webserver, it should fix the ca-certificates problem.
GoDaddy does not allowing sending via third party SMTP servers. They require sending all email via their own servers. If you need to use GoDaddy, we suggest using a transactional email service such as PostMark to bypass.
We strongly recommend using the built in snappdf package which is a highly performant PDF generator based on the headless chrome/chromium binary. This package is perfect for users that have root access to their server and are able to install the required dependencies if needed.
To configure SnapPDF use the following .env vars
PDF_GENERATOR=snappdf
As of version 5.5.12 we no longer prebundle snappdf in the release files, so if you have a new installation you'll need to manually invoke the download of the chromium binary, from the root of the project run the following:
vendor/bin/snappdf download
Snappdf is also the default PDF engine in our Docker image, so if you prefer a very simple installation please consider our Docker setup as it is very fast to get going!
You can use this command to test Snappdf:
./vendor/bin/snappdf convert --html "
Hello world
" test.pdf
A complete list of required dependencies is available here.
If you are on shared hosting, snappdf probably will be impossible for you to use as you do not have access to the subsystem to install the required packages. Instead, you will need to use a hosted PDF service, the two that Invoice Ninja v5 supports is PhantomJS Cloud and our own hosted PDF generator which can use for free to generate unlimited PDFs.
Phantom JS Cloud is the default PDF engine PhantomJS Cloud to generate your PDFs, the default API key that comes with a clean installation will no reliably generate PDFs, to ensure you can generate PDFs you should register for an API key on the phantomjscloud website and use this key in the .env file.
Phantom JS can be toggled on and off by setting the PHANTOMJS_PDF_GENERATOR to either TRUE or FALSE. The following .env variables are available for configuring PhantomJS.
PDF_GENERATOR=phantom
PHANTOMJS_KEY='a-demo-key-with-low-quota-per-ip-address'
PHANTOMJS_SECRET='your-secret-here'
The PHANTOMJS_SECRET can be any random value, it's used to bypass the client portal password.
If you experience errors with PDF generation, such as 500 Server error or Failed to load PDF document or a continuous loading bar, you must get a PhantomJS key here, Replace it with the prefilled key a-demo-key-with-low-quota-per-ip-address.
The default PDF generated as of version 5.5.12 is our hosted platform PDF conversion system. The hosted ninja PDF generator is an offsite PDF generator hosted by Invoice Ninja, which operate similar to PhantomJS. It is important to note that we do not store any information with this service, we simply convert the HTML your system sends into a PDF file which is return on the fly.
PDF_GENERATOR=hosted_ninja
When facing errors, first set APP_DEBUG=true in .env
This error message is observed when the queue attempts to perform a action where the queue user does not have the correct permissions. You may see this error if you run command line arguments as a user other than the web user.
This is most commonly see in Invoice Ninja where snappdf has been downloaded from the command line as a regular user, the permissions on the binary may prevent the webuser from executing the chrome binary when generating the PDF.
Always ensure that tasks run on the command line are executed by the web user, on Ubuntu this is typically www-data
The most common cause of this issue is running multiple version of PHP, if the caches are built with a different version of PHP you may see the above error as differing versions of PHP may not be interoperable on the same installation. Ensure you are running the same CLI and Web PHP version to prevent any errors/
You may need to restart the queue like this
php artisan queue:restart
This error indicated that the client_max_body_size parameter in NGINX is too small, you will need to edit your nginx config and increase the size
client_max_body_size 100M;
For users that rely on configuring a reverse proxy, please consider this post on our forum which details steps which may assist in configuring a reverse proxy.
If you are experiencing issues with the migration not running as expected please run through the following checklist:
jobs table in the database, it should be emptyEXPANDED_LOGGING=true Then attempt the migration again and afterwards inspect the log file in storage/logs/invoiceninja.logPdf generation will not working using the inbuilt PDF engine without some subsystem dependencies, please consult this resource for the list of necessary libraries for each supported platform Snappdf required libraries
Some systems do not allow cron configurations, one work around is to use a web cron service which can hit a defined endpoint which executes the scheduler via a GET HTTP request. Invoice Ninja has implemented a small service to allow a webcron service to hit the end point:
https://domain.com/webcron?secret=
To configure the service, you need to add a .env variable
WEBCRON_SECRET=password
It is possible to install Invoice Ninja in a subdirectory outside the doc root, to enable this you will need to update the .htaccess file (only if you are using the Apache webserver),
RewriteRule ^(.*)$ public/$1 [L]
should be updated to
RewriteRule ^(.*)$ subdirectoryname/public/$1 [L]
If you are finding that all your pre setup checks are passing however you keep falling back to the setup screen, this could indicate that you are missing the mysql-client library which is needed to perform the initial migration. If you are unable to install this for some reason (ie. XAMPP) then you'll need to run the migrations manually by entering the following at the command prompt
php artisan migrate:fresh --seed
This error is thrown from deep within PHP and indicates a permissions issue - most likely the public/storage and/or storage/ directory is not writable by the web user, depending on your platform, you'll need to run something like:
sudo chown -R www-data:www-data public/storage
sudo find ./ -type d -exec chmod 755 {} \;
and/or
sudo chown -R www-data:www-data storage/
sudo find ./ -type d -exec chmod 755 {} \;
If for some reason the UI becomes unresponsive, you may need to flush some subsystem configuration and rebuild. It is possible to do this by navigating to the /update?secret= route, ie. https://invoiceninja.test/update?secret= This will perform a number of system clean ups and may resolve issues resulting from an incomplete upgrade. To protect this route, you are advised to add a .env pararameter UPDATE_SECRET=a_secret_passcode this will restrict the route to users with the UPDATE_SECRET passcode.
It may help to add LOCAL_DOWNLOAD=true to the .env file, this will embed the image in the PDF rather than request it over the network.
If you are using the database for your queue's then sometimes you may see an error from MySQL
1153 Got a packet bigger than 'max_allowed_packet'
This indicates the insertion payload is bigger than MySQL is configured to handle! To work around this, you will need to increate the mysql variable
max_allowed_packet
To a larger value. Sometimes a value of 1024M is required.
It may also be wise to increase the variable
max_connections
as similar errors can be reported from the DB.
There was a report from the user who solved 500 error on their server by disabling ModSecurity.
Try these steps to fix the 500 server error when trying to login or editing company details
invoiceninja.zip but Source code (zip))sudo chown -R www-data:www-data dir/cd /home/domain.com/public_html/invoiceninja/ && php artisan migrate or simply php artisan migrate whatever works for you, select "YES"PHP Fatal error: Cannot declare class UpdateDesigns, because the name is already in use in /home/domain.com/public_html/invoiceninja/database/migrations/2021_09_16_115919_update_designs.php on line 0
In 2021_09_16_115919_update_designs.php line n/a: Cannot declare class UpdateDesigns, because the name is already in use
Delete that file and retry the command until it works and runs properly.
When changes are made to the container this can causes the cache to become stale in the application preventing it from booting.
The solution is to clear the contents of the folder bootstrap/cache, by either manually deleting files or by running /update?secret= which will also delete the contents of this directory.
This error is observed when the system has Composer v1 installed. Update to Composer 2 using the following command
sudo -H composer self-update
If you aren't able to adjust the open_basedir restrictions the following steps may help:
If you have command line access, you can reset your password manually by following the following steps. From the command line, navigate to the project directory and run
php artisan tinker
Then find the id of the user for the password reset
User::all();
Retrieve the user
$user = User::find(id_of_user_to_find);
Now lets reset the password
``` $user->password = Hash::make('password'); $u->save();
Want to contribute? Edit this page on GitHub!