TrueNAS SCALE 23.10.0 has been released!

[winnielinnie]

t's even worse for Core. At least SCALE has filled in some of these voids in its appliance's GUI.

As an example. How do you protect a snapshot in TrueNAS from destruction?

Core: Drop into an SSH session. Use the zfs hold customtag dataset@snapshot command. Better get used to using auto-complete for the snapshot names. Oh, that's right. You'll need to manually list and sort your snapshots to get a decent view, so that you can target the desired one.

SCALE: Visit the Snapshots page and find your snapshot. Check the "Hold" checkbox.


How to you remove a snapshot's protection?

Core: Drop into an SSH session. Find the snapshot that is being held. (Either you know it specifically, or you'll have to use a combination of "zfs list + holds + xargs" to find them.) Then you need to issue the zfs release customtag dataset@snapshot command.

SCALE: Visit the Snapshots page. Uncheck the "Hold" checkbox.





You get the idea. (To add insult to injury, the "Shell" in Core is nearly unusable.)

Sure, I'm a Linux user, but I do love the GUI way more than using the terminal. The problem is, the GUI in TrueNAS lacks many reasonable tools. (Especially for Core.)


I get that we're veering off topic, so I'll shut up now.

 

[Arwen]

...
I think the real heart of the problem is that Linux people tend to work more in command line. And treat their SCALE as a server with NAS functions, than an appliance that must be managed through the GUI & TUI, (aka command line CLI).
....

To be fair. There is very much that is "Generally recommended" that you just can't do in the GUI. And therefore have to do in the Shell.
E.g. Burn in of new drives, miscellaneous zfs & zpool commands (zpool list -v, for instance), just to name a few.
Obviously they can't have everything in the GUI. But I would like to see more of these "best practises" other common commands implemented.
...

Again, dropping to SHELL, (not Middleware CLI), to perform tasks has to be carefully thought out. I routinely make changes, that have no affect to the Middleware.

Enterprise users don't "burn in" disk drives, as they have likely a support contract that supplies them with preburned in replacement drives. And it is probable that many Enterprise users know what they can and can not do at the SHELL level, in respect to having the change either survive a reboot. Or just work at all for any length of time.

What I am trying to say, is either be careful and research what can and shouldn't be done at the SHELL level. It is simply meant to discourage casual SHELL work to prevent problems. Not stop someone.

One reason I use TrueNAS is that it has both SHELL access via SSH, and the ability to elevate to "root". Some small consumer NASes don't include such options. My prior NAS did, an Infant ReadyNAS 1000S.

 

[BossyBear]

I was able to apply the manual update file to my two TrueNAS CORE systems and the migration went very well overall.

My Gen8 system was perfect at 3rd boot (expected), I just had to clean up some app paths in cron tasks and remove tunables.

My Gen9 wasn't quite as perfect... a VM I had on it lost network connectivity because the device name changed inside the VM. I updated the NIC name in the netplan yaml file and it came right up.

Really easy overall.

Kudos ix!