Unable to open file for reading [https://invoice.[my_domain].us/logo/bFiEQM.png]

Self-Hosted | v4/Legacy
1

This morning I renewed the SSL cert for invoice.[my_domain].us, and updated my nginx proxy VM (which is separate from my ininja VM) with the renewed cert. After I was done the https lock logo turned from red to green and everything seemed to work perfectly.

However, after saving a new invoice I tried to send it via email, and I ended up with this error:
Unable to open file for reading [https://invoice.[my_domain].us/logo/bFiEQM.png]

The file that it referenced was my company logo file.

I noticed in this thread that the same error was received for an incorrect URL in the SSL cert.

I’m sure the URL is correct. I’ve delved through every log that I know about in both VMs and can’t find any related info. The owner/permissions on the cert/key files are identical to my other functioning sites. I don’t know what else to do. Can you please point me in the right direction?

2

Are you able to access https://invoice.[my_domain].us/logo/bFiEQM.png directly?

The ‘bFiEQM’ part looks too short to me, you can run the following query to check the database.

select account_key from accounts;

3

Yes, I’m able to access it directly from a web browser.

I abbreviated the filename because of forum limitations on the subject line. The actual filename is bFhYUiEQ6MBh0KUzerz0oEm0C0ATGnFQ.png.

4

Have you checked your web server error logs, there may be more details.

5

Yes, I did. Unfortunately there is nothing relevant there. Same with the Laravel logs.

I have postfix installed and configured to relay through Gmail so that I receive messages sent to root. What program does ininja use to send email?

6

It depends on the configuration in the .env file

7

I’m at a complete loss here. Why would the logo file be accessible from a web browser, but not when ininja tries to access it to put it in a PDF file and email it?

8

With the Nginx proxy you may need to set a TRUSTED_PROXIES value in the .env file.

https://github.com/invoiceninja/invoiceninja/blob/master/app/Http/Middleware/StartupCheck.php#L32

9

I added this to the end of my .env file and rebooted:

TRUSTED_PROXIES='10.1.1.0/24'

No joy. I also successfully accessed the logo file directly using the LAN IP of the VM, rather than my domain name. I also attempted to email an invoice using the same method in order to eliminate the proxy as a problem. It didn’t work. It appears that the proxy is completely transparent.

After doing all of this I scoured the logs again for any mention of the attempt to send an email. Not a word.

I’m stumped.

10

If you haven’t already maybe check if removing your logo fixes the error.

11

Removing the logo fixes the error, and allows the invoice to be sent via email. I can successfully upload another logo, but the error returns.

The permissions on the logo dir are 755 and the ownership is www-data:www-data.

12

Sorry, I’m out of ideas :frowning:

I haven’t heard this reported by anyone else, I’d suggest closely reviewing your Nginx config.

Maybe Google will have more answers…

13

I don’t know what the problem was specifically, but I rebuilt the whole VM and now everything works perfectly.

Thanks for the help!

14

Thanks for letting us know, glad to hear you were able to get it working in the end.

15

I’m in the same boat here. I just created a new SSL cert today, and I have my setup going through nginx as a reverse proxy. InvoiceNinja is setup to run behind apache2. I tried adding the IP to the allowed proxies paramter, no fix, I tried the IP range, no fix.

Now, the curious thing is that I can also remote into the local network and connect to the InvoiceNinja host directly, as in not going through the reverse proxy, and I still get the error.

For no I’m just going to take off my logo, but I really do need to get this fixed, and I’m not sure what’s going on. Permissions for the web files also looks correct.

Ideas?

16

Try applying this fix:

https://github.com/invoiceninja/invoiceninja/commit/2b2cfbc2e501bf1f60db6b48dfe9a1726173c122

17

I’m thinking it should be safe to just add that code change directly to the relevant php files, which I’m comfortable doing. But, is it a bad idea for a reason I don’t know?

Also, thanks for pointing me to that! :smiley:

18

You may want to back up your files just in case.

19

Woot those small code changes did the trick! Thanks! :smiley:

20

Great to hear, thanks for letting us know!