I’ve been using TrueNAS Core for many years, primarily as a file server and a media server using Plex.
My TrueNAS Core system consists of an ASUS P11C-M/4L motherboard, Intel Xeon E-2236 CPU, 64GB DDR4 ECC memory. 2x250GB Kingston NV2 NVMe drives for boot and 4x4TB Seagate Ironwolf drives in a RAIDZ2 configuration. This motherboard has 4 onboard NICs, but I am using only one of those NICs.
I now want to run TrueNAS Scale on the above hardware and I have a couple of questions.
Should I create a separate pool to hold my apps or is it ok to just create another dataset on my main pool to store the apps? I’ve been testing this and have used 2x250GB SATA SSDs in a mirror configuration but if it is not needed, I have plenty of room on my main pool.
At this point in time, I want to run Jellyfin in place of Plex. On my current server, I am running Plex and I have given it a separate network address and I like how that works, but in my testing with the Jellyfin app on Scale, all it seems that I can do is have a it use the same address as the server with a different port number. Is it possible to give the Jellyfin server it’s own address?
I currently use a Raspberry PI 3B to run Pi-Hole. This device acts as both my DHCP server and my DNS server. I would like to decommission the Raspberry PI and run the Pi-Hole app on TrueNAS Scale, but after reading all the documentation I could find, I can see no way to make configure it to have it’s own address rather than sharing the server address on it’s own port. Is this possible?
Eventually as my server sits idly most of the time, I would like to use it to try some other apps and VMs. But I’m just not really certain how to best configure my network interfaces.
That’s a good idea, as is putting that pool on SSDs.
It’s possible to give apps their own IP addresses, but it’s rare that I see a real reason to do it–in most cases, apps have their own port on the server’s IP which may or may not be exposed to the rest of your network (otherwise it may be behind a Traefik reverse proxy).
As with Jellyfin, there’s no real reason for Pi-Hole to have its own IP address; the ports it uses don’t conflict with what your NAS uses. But use the TrueCharts app for this; the “official” app has default ports that are just silly.
I can see using the same IP with a different port for my Jellyfin server. I’ve got it running just fine.
But I’m a little nervous setting up the Pi-Hole app. I have a small network consisting of my server, a backup server (not up all the time), 5 or 6 Windows/Linux/Mac clients and a couple of phones, iPads, DLNA client, router/firewall and TV boxes. If the DHCP server goes down, then most of my network goes down with it. So how will DHCP work if the IP address is the same as the server address. Does DHCP, when answering supply both an IP address AND a port number? The same goes for the DNS services it offers. When I do a DNS lookup, do I use both the server IP address plus the port number?
This just makes no sense to me. I’m not a “network guy” but have a basic understanding.
I would setup a separate SSD pool and create an apps dataset on that, and here is my rationale for that:
Most network storage is long-term which means few reads and fewer writes - and this is particularly true on a media server like yours. And when you want the data it is typically a single file that needs to be accessed.
Apps, on the other hand, have entirely different characteristics and (because it is relevant) I will use Plex/Jellyfin as an example (my experience is with Plex, but I suspect that Jellyfin will be similar):
Plex/Jellyfin app on your TV wants a lot of different data to populate the GUI - and the app on the server will need to access a lot of different files to get that data and send it to your TV - so read performance is very important. Using an SSD to store your metadata will likely make a BIG difference to how fast your TV app behaves. (Note: So will your network speed and the CPU power of your TV box.)
Plex/Jellyfin writes a LOT of metadata and it updates it on a regular basis. Using an SSD will help it get through its metadata updating faster.
Transcoding also uses intermediate files - and (depending on your memory size) it can be too big for memory /tmp files. Putting these on SSD will likely be a big help to transcoding speed.
Other apps will (IME) have a mixed profile - some will read and / or write a lot of data - and these will normally be the bigger apps. But there will be some apps that are small and don’t read or write a lot of data - but on the other hand they don’t use a lot of disk space. If these small apps were the only ones you are running, then use an HDD for them. Otherwise use an SSD and the small apps can live there too without any real impact.
While I understand how the ports work, I am running a few services and would like to give them a DNS entry.
Pihole.gaut
Qbit.gaut
Galactica.gaut
if they are all just different ports on the same IP, then using the url does not get me to the right place.
today I am using bookmarks to the IP : port and this works fine, but I would like to understand the process to get separate IP for my use case.
thx
Assuming you’re talking about the web interface for those apps, the real way to do that is with a reverse proxy–if you’re using TrueCharts’ apps, that would ordinarily be Traefik; if you’re using iX’ apps, I guess you’d be stuck with something like Nginx Proxy Manager. You then point all the DNS records to that proxy, and that proxy determines which backend service to talk to depending on the name you request. I run dozens of TrueCharts apps this way using Traefik, and it works seamlessly.
If for some reason that isn’t an option, with TrueCharts, you can use MetalLB to expose other IP addresses for your apps; consult their docs for how to do it. I don’t know if or how it’s possible to do this with iX’ apps.
Or, don’t use any apps and use the containers from dockerhub directly. This will then translate to Electric Eel. I have 20 apps, all custom apps. It’s very similar to running docker so if you know docker… You can give custom apps their own IP where needed, I do for a few like mariadb and Emby.
Probably not. iX doesn’t have any ingress solution in their catalog at this time, so if they don’t develop it you’ll need to figure it out with some other software. Or do it in a sandbox. Or use whatever TrueCharts is going to come up with.
If you’re using TrueCharts’ apps, it’s very well integrated and their docs are pretty decent.
Once Electric-Eel BETA is out… the Community can add Apps to the community catalog and test the private/internal networks. The goal is let the community innovate with better/easier-to-use tools.
As an alternative to the reverse proxy, you could set up Docker in a sandbox and use macvlan networking to give your containers their own IP address. And with the next version… you will just keep using the sandbox (and if not, what you do in the sandbox should be very close to what Electric Eel will do).
Of course, you’ve just thrown away the community’s work on apps so far. It seems likely that’s going to impact “the community’s” willingness to start over.
You created a k3s-based ecosystem for apps and released it with Angelfish
You invited–requested, even–the community to develop apps under that ecosystem
The community did, in fact, develop apps, such that the majority of the apps in the iX catalog are “community” apps
You’re now throwing that ecosystem away, and all their work with it.
You asked the community to do work in developing apps, and you’re now throwing that work away[1]. There’s no clearer way to say, “we don’t value your work,” and I don’t think that’s going to motivate the community to do more of the same sort of work. Your migrating their work to the new system, if that’s what you’re doing, might mitigate that. “Docker is so much easier” might offset that. I strongly doubt that “you can still run k3s in a sandbox or VM” will at all mitigate or offset it[2].
Maybe I’m speaking out of turn here–after all, I’m not one of the folks whose work is being thrown away. But that’s how it’s looking from the outside.
What does this mean, exactly? You’ve said it several times in this context, but what does it mean? Obviously my Dragonfish installation isn’t going to disappear once EE releases. I assume you aren’t going to pull it from your download servers. But in the past–under FreeNAS, and then under CORE, Release N became EOL nearly immediately upon Release N+1. No further development was taking place on Release N, not even bug fixes, no real support was offered for Release N, and users were told to upgrade to N+1. Is that not the case with SCALE generally? Is Dragonfish an exception? Or do you just mean that “you can continue to use an EOL release if you choose”?
and I’ll note this isn’t the first time iX has pulled a move like this, though I doubt many here remember the iX wiki coming and going and coming again and going again ↩︎
…and to be clear, I’m addressing only the community apps in the iX catalog. I’m not addressing TrueCharts or other third-party app catalogs (if any), though I think many of the same points apply to that context as well. ↩︎
Not true… we expect to migrate 100% of TrueNAS Apps including Community Apps.
Yes, exactly. Users that have custom Applications that may be difficult to migrate will have an extended period to make the transition. Dragonfish is a first class release, it will have a large number of Enterprise users and it will be polished well.
The release of Electric Eel in Q4-24 does not require a transition even during 2025.
There are still a large number of users on TrueNAS 12.0.
Just to clarify, I don’t know where this FUD about community apps not being carried over came from. We explicitly stated that all apps in the iX catalog will be moved over, including all the community train ones, which are the bulk of them. We’ve started a list and will be checking them off as they get merged into the new Apps catalog.
Again, this is early, nothing is even ready in the nightly images yet, so check back on it in another month or so. Once existing apps are moved, I expect we’ll move on adding new ones, as well as encouraging community to contribute more if they so choose.
I’m not aware of anyone claiming that community apps won’t be carried over, and I’m certainly not claiming that. But if I’m the one who implemented, say, Tailscale in the current catalog, and you reimplement it in the docker-based catalog, you’re still throwing out my work in favor of the work you did yourself. Right? So in that regard, this:
is good to know as a user, but not relevant to the question.
Yes and no. A lot of the work that went into a Helm chart is pretty directly translatable to the equivalent Compose App. So I wouldn’t say its all being “Thrown out” like that, rather it is being used as a template to help convert to the new format.
That said, if somebody has a particular attachment to their adopted community app, we’re all for them assisting in the migration if they so choose. We’re not going to turn it down, that’s for sure. As we say, pull requests welcome!
I’d recommend you think of it in classic open source perspective. The original work is used as the basis of v2. The project lives on and the use-case is still supported through both Dragonfish and Electric Eel.
With the transition, its easier to use the App in combination with other Apps.
