TrueNAS SCALE 24.10-BETA.1 is Now Available!

Don’t want to jump to conclusions but after some experimenting, found running midclt call -job k8s_to_docker.migrate tank looks to be a workaround for my case and may be useful if anyone else runs into apps not migrating after upgrade. Will need to see what the jira ticket comes up with though as I’m not sure why it works after failing the first time :stuck_out_tongue:

3 Likes

Updated to Beta1 from 24.04.2 on my 4GB potato system bare metal and it seems to have worked just fine :slight_smile:

2 Likes

+1 for using separate IP(s) for apps, as well as multiple “container stacks” (if that’s what they are referred to as?)

When the brilliant jailmaker was released (+ equally brilliant support info by @Stux) I moved 7 of my existing Dockers off a Linux VM into into a jailmaker sandbox (call “docker”) with it’s own IP… happy days!

Much later I went to add my UniFi Network Application as a Docker instance and found I had a port clash with TVheadend and so I created a new sandbox called “docker2” with a new IP and put my UniFi Network Application and Mongo DB into that… back to happy days!

So yeah - GUI support for custom IPs and also multiple “container stacks” would be fantastic.

Now onto health checks. I don’t see too many people talking about these but to my way of thinking it makes a lot of sense for container dependencies. I only found out about them recently and implemented the following for my “docker2” (UniFi + Mongo) container stack:

root@docker2:~# cat compose.yml 
services:
  unifi-db:
    image: mongo:7.0
    container_name: unifi-db
    volumes:
      - /mnt/data/unifi-db/db:/data/db
      - /mnt/data/unifi-db/init-mongo.js:/docker-entrypoint-initdb.d/init-mongo.js:ro
    healthcheck:
      test: echo 'db.runCommand("ping").ok' | mongosh localhost:27017/test --quiet
      interval: 10s
      timeout: 10s
      retries: 5
      start_period: 40s
    restart: unless-stopped
  
  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:latest
    container_name: unifi-network-application
    depends_on:
      unifi-db:
        condition: service_healthy    
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Australia/Sydney
      - MONGO_USER=unifi
      - MONGO_PASS=unifipw
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
    volumes:
      - /mnt/data/unifi-network-application/config:/config
    ports:
      - 8443:8443
      - 3478:3478/udp
      - 10001:10001/udp
      - 8080:8080
      - 1900:1900/udp
      - 8843:8843
      - 8880:8880
      - 6789:6789
      - 5514:5514/udp
    restart: unless-stopped

The elegant thing about this is this is that when I use my script “dcdown” (alias for docker compose -f ~/compose.yml stop) it stops the app fully before stopping the DB.

Then when I use script “dcup” (alias for docker compose -f ~/compose.yml up -d) it works in the reverse order, and does a health check on the DB before starting the app. Simply brilliant.

image

So just putting it out there to help others who might find this useful, and also as a feature request - to be able to add health-check support either directly via the GUI or as a custom Compose option which then won’t get stomped on later on with an app or OS update. Cheers, Gcon.

PS. “unifipw” above is just for the example :smiley:

1 Like

I just updated to this EE Beta … I didn’t see where to update my TrueCharts Plex app so I just installed it fresh and it’s up and working great … transcoding with my A380 is working (says hw when I force a transcode anyways)

Now I can have an up to date Plex server again! Thanks a bunch guys!

eventually I’d like to install UniFi Controller and Frigate … I’ll make sure Plex is a 100% first though

2 Likes

TrueCharts was based on Kubernetes apps. Eel switched to Docker. Your old Plex app not working on Eel is expected behavior :slight_smile:

Good to hear that the A380 is working out the box! I have it working on Dragonfish but it took some effort, at least during the Dragonfish Beta days.

Looking forward to migrating to EE this weekend :slight_smile:

1 Like

Using macvlan you can assign a dedicated MAC + IP to a given container.

Ipvlan will do the same without the Mac.

This is like having a container on your LAN… but networking to the host does not work out of the box (host can’t route back to container, a bit like bridges and VMs)

This routing problem is something jailmaker takes care of.

Another approach is to use an ip alias on the truenas side, you can then bind to that on the docker side, no routing issues, but the issue is that TrueNAS likes to bind most of services to 0.0.0.0 which is all ips.

Health checks can be integrated into apps, and they can be used with compose, which right now you can use in dockge etc

2 Likes

I just updated my SCALE to EE Beta 1 and everything including migration of some of my apps were successful migrated and I lost some and can’t find them in the new catalogs like Recycler and NZBget. I know custom app is not available right now any idea how to add or install any missing apps at the current version?

Install Dockge, Portainer, or use docker from the CLI to setup custom. Custom Apps UI will land in the RC1 later in Sept.

3 Likes

Would upgrading to 24.10 BETA.1 possibly help us having the pcie passthrough problems such as the one in this thread: PCI passthrough in VM no longer working in Dragonfish 24.04.0 - #6 by millerwissen

It is a production server i’m running but the stable release isn’t functional, though I don’t see any improvements specific to pcie passthrough, I also have to manually do the G35 machine change through cli i didn’t see that being added to the GUI.

Feature request here

1 Like

well … Plex was running good … now it’s not working with:

Critical: libusb_init failed

showing in logs. Plex says it is running but can’t pull up the web ui

googling around as I’m sure I am not the first to have this issue, lol

EDIT
odd issue I suppose … but resolved now.
Though the Web UI wasn’t accessible , I could still pull up the plex app on my PC and changing “secured connections” back to “preferred” from “required” … fixed the issue

This may help with setting up and using dockge

1 Like

Is anyone getting:

“Boot pool status is ONLINE: One or more features are enabled on the pool despite not being requested by the ‘compatibility’ property…”

After upgrading from 24.04? I haven’t upgraded my two data pools, and I definitely didn’t upgrade the boot pool.

Migrated from the latest Dragonfish to the Eel beta. Overall, no major complaints (it’s a beta!). Enjoying the new interface but haven’t fully explored everything yet.

Here are the minor issues I’ve run into:

  • A qbittorrent app ‘migrated,’ however I was unable to access the web interface. I believe this is due to my use of an ‘alternative UI’ (callmebruce/nightwalker). The theme was in a host-mounted path on Dragonfish. Should have checked shell for the app, but I’ve already deleted it. **This was because when you click “Web UI”, it takes you to http://host:port/admin and prior to the migration it took me to host:port, which is what I had configured. Easily fixed.
  • Tailscale did not migrate although it’s listed as an App that should. No problem.
  • I unset the App pool because I wanted to start fresh. Removed the old ix-applications dataset from my pool. Not sure if it’s related to the next issue:
  • When I went to “Storage” page, there was 1 disk with an exported pool named “Apps.” I’m not sure if this is something I created in the past, a temporary pool created for the migration, or where the “App pool” that I unset was created. Going to “import” listed no pools available for import. Trying to add the unallocated disk showed no disks available to attach. I determined the pool was on nvme8n1p3, which was odd since nvme8n1 was a mirror for the boot-pool (nvme7n1). Did TrueNAS create a partition/pool on my boot-pool for Apps when I upgraded? I detached the drive from boot-pool, wiped it, couldn’t re-attach to boot-pool due to a ‘3-way mirror not possible’ error. Rebooted and was able to attach the disk to recreate the boot-pool mirror.
  • Set my optane pool for Apps. When I went to install the first App I saw this error listed on the right in the Available Resources box: “Available Space: [ENOENT] None: PoolDataset optane/ix-apps does not exist” It didn’t seem to impact the installation of the app. I do not see that dataset and was unable to manually create it.
  • Noticed an intel driver error during boot. Haven’t fully tested it yet, but it looks like I still will need to switch TrueNAS to dev mode to add the driver manually? I can see the benefits of this but will need to figure out the ‘correct’ way to do it.

I installed the Beta from scratch just to make sure it wasn’t a migration issue and received the same error above about optane/ix-apps not existing.

Need an hour or two to set everything back up, but will follow up if I have anything to add :slight_smile:

1 Like

More likely you did in the past and have forgotten :wink:

It’s almost a text book implementation of “how do I use the spare space on my boot nvme for apps”

And a good illustration of why it’s not recommended.

1 Like

Really digging the updated dashboard. Very convenient to fit a bit more data on the screen without having to scroll. Good work to all involved.

Wish the pool status fit on the half-height panels, but I’ll take it :slight_smile:

4 Likes

One other neat feature in EE is that we now generate audit entries for commands run via sudo (granted this is more interesting for businesses than home users).

1 Like

Loving the changes to apps, so happy to see Docker back in the mix.

Is there intention to bring back disk space reports? There is still a link in usage, but still no report.

Thanks,

One other change on SMB side is that I’ve added mechanism to put some backpressure on clients that are writing heavily over something that’s not conventional network. We saw some issues in DF with clients using loopback mounts (in particular proxmox host writing to TN) where the smbd process would build overly large write queue (sometimes building up multiple GiB). The queue depth that can build for an smbd is now capped to prevent OOM situations.

So if this an issue you’ve been seeing, it may be worth testing BETA1 or RC. On the NAS services / non-apps side of product I don’t see much that will change between BETA and RC (unless someone reports a serious issue).

Which openzfs version is in electric eel beta1?