Well, this was an interesting one. A client’s production XigmaNAS VM, running on UFS2 (because it’s a VM, and ZFS is on the host beneath it) needed expansion today.
Unfortunately, expanding the size of /dev/vtbd1p1 removed its UFSID label–and just trying to recreate the same UFSID using the glabel command results in the partition getting the glabel label/ufsidnumbers, rather than simply ufsidnumbers!
The fix–and the only fix, as far as I could discover–is to edit /conf/config.xml on the XigmaNAS VM (either using Tools-->File Editor in the webUI, or on the command line), find the <mount> section which refers to the expired UFSID, then change the <devicespecialfile> attribute.
If you actually have a new UFSID on your expanded partition, you can use that as the new value of <devicespecialfile>. I never got a new UFSID and couldn’t figure out how to create a proper one, so I just changed mine to the raw device name–which, for me, was /dev/vtbd1p1.
Once you’ve updated the <devicespecialfile> in /conf/config.xml, go to Disks-->Mount Point in the web UI, and click the Retry button next to your broken mount–it should connect fine.
PS: “Oh, no, I can’t find a <mount> section in /conf/config.xml at all!” That’s probably because you deleted the broken mountpoint entirely. Go back and recreate it–it’ll still be broken, because XigmaNAS is still trying to use that old UFSID. That’s okay–recreating the broken mountpoint will put the broken <mount> section back in /conf/config.xml, where you can edit it as described above just fine.