It's been a little while since I built Invoice Ninja, but I don't recall reading anything about it being a requirement. Regardless, if it's required for the base functionality, then it should be pre-installed. As this appears to be a bug, I've opened an issue so we can fix it in the next release.

FWIW on closer inspection, I note that there are a couple of other PHP extensions which may be dependencies, and aren't included by default. Namely: "php-xml" & "php-mbstring". Regardless I suggest that you install them too (even if they aren't strictly required, they won't hurt). They can be added to the instructions I posted above - at end of the line that includes 'php-gd'. Alternatively, they can be installed separately/after:

apt update
apt install php-xml php-mbstring
systemctl restart apache2

Anyway, hopefully that fixes it up. Please do not hesitate to post back if you have any further issues/questions.

It's definately a bug then, so thanks to you fro reporting it and extra points for confirming the fix! :)

As I noted in my previous reply (and the bug report I've now opened), that it seems likely that there are some other deps missing too. If you haven't already, I suggest that you install them too. If you don't do that now and you hit any other weird issues, then I suggest installing those 2 additional packages as a first step and see if that fixes the issue.

Thanks for this additional info. Not only will it help others using the current TurnKey Invoice Ninja applaince, but it's something that I'll look to add in to future TurnKey releases.

Firstly, thanks for the heads up. And welcome to TurnKey! :)

So the short answer is "yes, but...". FWIW we do always hope to follow upstream's "latest stable". The pragmatics though mean that isn't always the case (especially with faster moving projects).

The longer answer (with context), is yes but not sure when. With a small team and 100+ appliances on a multitude of platforms, keeping every one on the latest upstream version is a big job! Plus the more time we spend maintaining the current library, the less time/energy for developing other/new features, etc. Every time you say yes to one thing, you are in effect saying no to a million other things. So we need to balance our priories and resources.

We also have the problem of keeping previous versions. Ideally we try to keep as many past releases as we can. But with each release around 500MB (min ~300MB, max 1.2+ GB), a number of different build types and 100+ appliances, the size of all those files adds up. Plus it's not just about our storage costs, it's also about being a good open source citizen. As an open source library, all our mirrors are provided to us gratis so we need to keep them happy! So in that context the less files on the mirror the better.

Despite all that, we are currently doing a refresh of the images. We made some major changes to our custom software in v16.0 and some of the earlier ones includes some buggy packages that we've fixed. Plus as I said above, we do try to keep them as up to date as possible.

Unfortunately though, Invoice Ninja has just been (re)built. Like literally only a few days ago. I still haven't updated the website or announced via the blog (both will hopefully happen today), but the image is already on the mirror. So I'm a bit loathe to rebuild it again so soon, especially when we're only about 1/3 of the way through the library. OTOH, v5.x is a major change/progression so making an update/rebuild to include that certainly has additional weight.

So in the meantime, I've opened an issue on our issue tracker.

Hmm that is a weird one then!? Have you tried to reproduce the issue from a normal browser too? And/or different browsers? And/or from a desktop? (no need to check them all, but at least checking from one desktop browser would be good).

If you can reproduce it, then the logs would be helpful I'm sure. Ideally if you can explain how I can reproduce the issue myself (ideally via a desktop browser), I'm fairly confident I can develop a fix and/or workaround.

Thanks too for your feedback. I agree that Invoice Ninja is a much better SMB invoicing tool than Simple Invoices was! :)

If you are interested in upgrading to v5.x it should be possible on your current server but as OZ noted, their docs are a bit of a mess ATM. I'm hoping that once they get everything updated and things settle down a bit with v5.x that they will get tidied up.

PS thanks too for the heads up that they have an Android app. I should add a link to that (and the iOS app assuming there is one) to the appliance page!

Hmm, yeah if you only experience it in the Android App, that does suggest a bug in the Android app. Although having said that, the Android app uses the API, whereas AFAIK (although could be wrong...) the v4.x web app (accessed via a web browser) doesn't directly interact with the API. If my understanding is correct, then it may still be an issue on the server causing this.

Thanks for reporting the issue Jays. I've opened an issue on our tracker so it doesn't get forgotten.

As glad as I am that you reported it, now that I know the cause, I'm a little frustrated and annoyed that this slipped through! Argh!

It turns out that the updated Invoice Ninja appliance has both Apache and Nginx installed... *sigh*. Removing Nginx resolves that "403" issue. I.e.

apt purge --autoremove nginx nginx-common

Note that will remove about 10 packages (except for 'libgeoip1', they should all start with 'nginx..' or 'libnginx...'). Once removal is complete, restart Apache:

systemctl restart apache2

And now things should be working...

FWIW, part of the cause of that occurring is that NodeJS is now required for Invoice Ninja v5.x. Another part is that since we added NodeJS based apps to our library, they have used Nginx (as a reverse proxy for NodeJS server). However, now in 2022 NodeJS has become a common component of lots of software stacks - even ones based on our LAMP appliance. So the proper fix will be to remove Nginx from the NodeJS plan and explicitly add Nginx to their relevant plans.

Apache and Nginx don't necessarily conflict with one another. However, by default only a single application can listen on any particular port. So with default config, both Apache and Nginx are trying to use ports 80 & 443 (vanilla HTTP & HTTPS respectively). Whichever starts first wins and the other will fail. It turns out that in the scenarios we used during build and testing (including my final ISO test), Apache starts first and Nginx fails. However as we weren't expecting Nginx, we never noticed. For whatever reason, in an LXC container it appears that Nginx wins more often - hence you discovering the issue and me being able to reproduce it so easily...

I'm not 100% sure when we'll do a fixed re-release, but I intend to apply the fix to the codebase shortly.