I use nethserver as file server at home. For storage, I use an external 8-bay HDD with zfs-raidz1. The mount point of most pools link to /val/lib/nethserver/ibay/somedirectory.
The filesystem works nicely and stable, but when it comes to deeper updates (kernel updates) I run into an issue.
I think it is recommended to uninstall zfs before kernel update. Before uninstalling, I need to export the pools. But any attempt to unmount/export datasets results in kernel locks (system/umount), soon the machine will stop responding to any input and I need to force power it off.
I don’t feel comfortable with this.
I tried stopping some services related to file sharing before unmounting, but it didn’t do the trick so far.
Do you know the reason for the kernel lock when unmounting the zfs, and what I cloud do to resolve it?
You could set the majority of services in NethServer to stop.
Try an unmount then. If not, reboot your NethServer, then unmount. (Or unplug the network when rebooting. With a fixed mount, this may hang, just replug in the LAN…)
You may need to repoint the mounts to the local folder…
I think NextCloud, SoGo, WebTop, NFS, Samba (Audit) could have a role in this, maybe others, depending on what you’re running on the server.
For the record: I stopped nmb, nsdc, httpd, plexmediaserver and dokuwiki. Then I was able to export the pool without any issues, remove zfs, upgrade nethserver and reinstall zfs. It is a very slim instance, not many more extra services are installed.
I tried stopping services the times before (other ns/kernel upgrades) when I ran into the kernel locks - except nsdc. Does nsdc (the domain controller service) hold zfs shares?
Maybe something else changed in the meanwhile. This time (upgrade to 7.8) I asked before trying the troublesome path.
All shares in NethServer are controlled by AD, if you setup your account provider for AD. Most people use AD on NethServer, as this gives you authenticated shares, not “public” shares.
So in some form, the answer must be yes. Although I can’t say what exactly. It could also be a client holding on to stuff, but a reboot would have solved that. So I assume the nsdc also could be the “culprit”…
But whatever the problem, never hesitate to ask here. If I can’t help, there are plenty of others here who can and do help too!
That’s one of the things which makes this forum so special, and in my opinion one of the best in open source I’ve seen and participated in 35 years!