TrueNAS 24.10-RC.2 is Now Available!

Am I wrong in thinking that I was expecting NVME SMART reporting in EE?

In order to minimize possible regressions and testing requirements, the decision was made to focus on the one issue that was causing upgrade problems for a number of users. The IP issue has a relatively simple workaround that was documented with the RC.1 release notes.

Application Web UI buttons, accessed from the Application Info widget, can default to a 0.0.0.0:port address after app install or restart (NAS-131308). Refresh the browser window, or manually access the port in the form hostname or IP address:port, to correct button function and access the app UI.

Once the proper IP has been established by refreshing or manually navigating to it, the button continues to link to the correct address, which is what @Chris_Holzer seems to be experiencing.

NVMe disks should be showing SMART test options on the Storage > Disks screen in EE.

1 Like

thank you. i was confusing the multi-report functionality with TN

Upgraded from RC.1 to RC.2 and had a boot issue with Grub:

error: unknown checksum function 0.
alloc magic is broken at “Address”

Turned out I had secure boot enabled. I disabled it to get it to boot, but will look at it when I have more time.

Thanks so much for that hint - I am not really familiar with all the different tools in the Docker ecosystem.

Deploying

  • onlyoffice
  • peanut
  • uptime-kuma

went without a hitch. And I have an (apparently) read-only status display of all apps deployed via TrueNAS and full management of all deployed in Portainer.

One question, though, if you happen to know:

Are these resource limits only for the Portainer application itself or are these what is allocated to all apps managed by Portainer in total? Or for each dependent app individually?

Which “knobs” exist in this part of the system to get individual limits?

Thanks!
Patrick

EDIT: found it - Advanced container settings | Portainer Documentation

1 Like

If you want a more low level experience ;), you can try Dockge too, it’s essentially a glorified compose editor, so you can just point it at your “stacks” directory and then manage the stacks with Dockge, or CLI, or even VS Code etc

I cannot quite point at what makes me experience TrueNAS’ interface as more clumsy/complicated for custom apps. Just a gut feeling. Portainer feels mature and cool.

I am not intending to move any of my core productive installations like e.g. Nextcloud from FreeBSD jails anywhere. The SCALE system is for applications that do not manage critical data and are more pain to deploy in a jail than in Docker. @victor’s scripts help a lot to run e.g. MineOS on FreeBSD, but still. Onlyoffice on SCALE is way less hassle.

That being said I would love the iX app catalog to grow. I don’t understand why e.g. Onlyoffice Document Server is still missing. It’s the preferred MS Office integration for Nextcloud. Beats Collabora on all criteria I care about.

Kind regards,
Patrick

Thank you, however looks like things didn’t go well.

8 apps successfully migrated.

Plex failed to create migrated app due to Field was not expected\n[EINVAL] values.storage.logs.type: Invalid choice: tmpfs\n. Looks like having Plex Log and Transcode Storage in memory is not supported on the docker version of the app or just a bug?

14 apps failed to migrate due to cannot promote dataset outside its encryption root

Also, migration invalidates TailScales API key even after restoring to DragonFish. This is however more a feature than a bug I think.

Should I create Jira issues for all of these?

  • Migration script not waiting until passphrase encrypted Applications dataset is unlocked before running.
  • Plex fails to migrate if storage is set to Memory.
  • Migration failed for “cannot promote dataset outside its encryption root”.

Not from my experience, at least here on Firefox. It’s very much reminiscent of SCALE’s other GUI issues that are only resolved by a hard refresh (CTRL+F5) except that doesn’t resolve this one.

Cheers for the explanation r.e. why the fix wasn’t included.

I’d take the view that if you have an encrypted applications dataset that I would not expect the migration to run on this without it being unlocked. So I don’t believe that requires a ticket.

The other 2 I would recommend you raise tickets for.

Same issue here after upgrading to RC2 from RC1.

Needed to get things working again - rolling each app back brought them back to life (and then I was able to upgrade to latest again after).

I’m not saying it should be able to migrate an encrypted applications dataset that is locked. Saying it should not run until it is unlocked/decrypted. It just seems like an oversight to me since an unencrypted dataset and a decryption key based encrypted dataset would both be available at boot. Just not a passphrase based encrypted dataset.

Edit: I just added my migration issues to this…
https://ixsystems.atlassian.net/browse/NAS-131561

It seems that the developers did not considered that the application dataset could be encrypted. Indeed why? I can understand encrypting the data, but the apps?

This seems still weird to me, does noone know how to fix it?

It’s a bug maybe? When you unset your pool you can see that the datasets are still there by running zfs list. Just remove them.

Unsetting is not removing relevant datasets.

Deleting the app doesn’t delete the app data. The default path for apps in Electric Eel is here:

/mnt/.ix-apps

You can either delete the app data from within that directory or reinstall the app in a host path you have (more) control over.

1 Like

What @rambro1stbud said. You could also just install the app using a different container name (accepting that will leave some cruft behind).

The stable release version will add a checkbox to clean up the iX Volumes:

image

8 Likes

Great, thank your all for the answers!

What are the expected default Samba create/file mask and directory mask in this version? Docs and tooltip in the UI mention 0666 and 0777.
However, from a quick test, this does not seem to be case.
Changing the values to 0666 / 0777 in the UI does seem to work though, even if this is supposed to be the default…?

/etc/smb4.conf on a fresh install shows create mask = 0744 and directory mask = 0755. This does not appear to match docs or the tooltips.

Looking at the code, the defaults also seem to have been changed in this refactor PR? NAS-128754 / 24.10 / Refactor SMB and Directory Services plugins by anodos325 ¡ Pull Request #13640 ¡ truenas/middleware ¡ GitHub (now in util_smbconf.py, previously in reg_global_smb.py)

I’d just appreciate some clarification on what the defaults should be.