ZFS migration, pool import

Background:
I’ve had a XigmaNAS system for about 6 - 7 years as a repository of photos video (own and d/l) and a backup area for older archive stuff. Around 3 years ago the gui stopped working and the system was only accesible via SSH and CLI.
It continued working - as in serving SMB shares, which is it’s primary purpose
It doesn’t shutdown properly.
Conclusion over at XigmaNAS forums was corruption on the boot drive somewhere.
I was going to reinstall but not sure which version and around that time set up my first TrueNAS, so the plan became migrate zfs pool at some point onto a new server.
For various health reasons that got shelved but now trying to do that.

Currently:
Data backed up elsewhere and can still go back to Xigmnas boot if necessary as long as I don’t mangle the pool somehow.

New server plan currently not going so well as got stuck in a QNAP external cage issue, which I now know I am unlikely to get working with TRUENAS, even if I can install drivers to get the hardware recognised due to some other issues.

New, new plan therefore is replace XigmaNAS with TRUENAS on existing hardware.
Machine is an old (circa 2011) Supermicro stuffed in a tower case with 6 x 12TB in RAIDZ2.

Progress so far:
New system drive installed, TrueNAS community installed on that and upgraded to 25.04.2.4.
Network fine and SSH setup for admin.
Pool imported. I can see the main dataset (named Primary) and the child datasets I previously set up for SMB shares.

Obviously config didn’t come across as I didn’t know whether an old Xigmanas config would import on TrueNAS and figured it would be easier to recreate as there aren’t many users and apps will be from scratch here.

Created a single user, to be able to setup an SMB share, then
Started with SMB shares, but I’m seeing nothing via GUI other than /mnt in the easy path filling function. To be clear I DO NOT see /mnt/mnt/… as most others do I have an empty /mnt. See upload screenshot. Note the I have expanded /mnt by clicking on the arrowhead. That’s it.

Nevertheless I figured this might be a mount point issue as it seems similar to what others have experienced.

o/p from zfs list and zpool list & mount are as upload:

zfs and zpool list and mount.txt (10.3 KB)

The Primary entries with /mnt/mnt… suggest that this probably is a mount point issue even though I don’t get the same result in the share creation process.

However when trying to follow one of the various methods of how to fix mount point issues, specifically:

as root on console:
– zfs set mountpoint=/mnt/poolname poolname
– zpool export poolname
– zpool import poolname ( /mnt/poolname is fixed)
– reboot (mointpoint stays fixed)

I get stuck on the export line with a response
root@Matrix[/home/truenas_admin]# zpool export Primary
cannot unmount ‘/var/db/system/samba4’: pool or dataset is busy

Given that the SMB service isn’t up and running as I haven’t got to that yet, I’m not sure what might be using it.

Furtling around some more I noticed all the legacy entries in the zfs list and that one of them is indeed a samba4. But I don’t really understand what these entries are as I never specifically created them. Whether they are XigmaNAS only or why TrueNAS might be using one of them I haven’t the knowledge.

Also while searching for some of this I came across an error that suggested that under TrueNAS “Global” might be a reserved identifier that I can’t use in dataset names. Anyone care to comment as it’s been that name for about 20 years over 3 NAS’s

Questions:
Am I going in the right direction with mount points?
How to overcome the SAMBA error for the export?
Any other gotchas going from XigmaNAS to TrueNAS?
Do I need to deal with those legacy entries in the pool at the point it works enough I’m not going back to XigmaNAS? If so how?

Thanks.

If you want it the TrueNAS way then don’t set an explicit mountpoint. Use zfs inherit to set it to default:

zfs inherit mountpoint poolname

If you zfs get the property it should have SOURCE=default. Here’s an example from my system:

$ sudo zfs get mountpoint tank
NAME  PROPERTY    VALUE       SOURCE
tank  mountpoint  /mnt/tank   default

TrueNAS will always prepend /mnt (using zfs import -R /mnt), which is why in my example I get a mountpoint of /mnt/tank instead of /tank.

The first pool you import in TrueNAS will be used to create system datasets. These are the <pool>/.system/... datasets that you noticed. These datasets will be mounted by TrueNAS, you can look at the mount table to see where they end up at:

$ mount | grep .system
...
tank/.system on /var/db/system type zfs (rw,noatime,xattr,noacl,casesensitive)
tank/.system/cores on /var/db/system/cores type zfs (rw,noatime,xattr,noacl,casesensitive)
...

If you want to know what is blocking /var/db/system/samba4 use fuser:

sudo fuser -vmM /var/db/system/samba4

I suspect the middleware is using that dataset even if samba is not running.

Generally, you should try and do zfs export operations on the WebUI. There might be some interference otherwise. Or maybe stop the middleware before doing them (service middlewared stop) - assuming you have SSH access.

No clue if Global is reserved.

How did you import the pool?

If you used the command line /sbin/zpool import ..., then I suggest you export via the command line (even if you have to force the export) and then import via the GUI.

TrueNAS is an appliance and not just ZFS on Debian. It maintains it’s own configuration and view of the data, which you bypass when you use the command line tools (which is why they are not on the default $PATH).

The pool import was via the TruNAS web UI.

Obviously the export from XigmaNAS was via the CLI as I had nothing else with that.

OK, good news is that your zfs inherit mountpoint worked. I’ll need to go find out why and how another day, but for now thank you.
(zfs get mountpoint was showing source as local prior to using command.)

Prior to doing that I did try to find out what was blocking the Samba4 db. Whatever it was it wasn’t the middleware as stopping that had no effect. I stopped trying to find out why at the point the inherit command had it working.

From your explanation the .system datasets must be TrueNAS ones (whether or not there were equivalents in there from XigmaNAS prior to import). Again I’m not going to worry about that.

The Global naming issue I have now discovered is a SAMBA thing. The error message indicates that it’s used for a section name, so I’m guessing that the GUI fills in sections of the Samba configuration file and that’s where it’s a reserved name. Why it wasn’t showing up on other NAS I have no idea unless maybe the reserved name is from a newer version of Samba. (Seems unlikely but again I can work round this so not bothered).

1 Like