In QuTS it is currently possible for the user to take a snapshot or zfs receive snapshots. The user could inadvertently do this - there is no warning. This results in immutable snapshots that cannot be cleaned up unless the entire share is deleted, or the entire device cleared and re-inited (if the dataset is not one known by the UI).
Since support will not fix these situations, I strongly suggest you either disable the zfs CLI commands outright, or warn the user that they may create snapshots that are permanent until the device is reset completely.
No all snapshots are immutable. QuTS intercepts all the destroy operations. If it’s a snap then it can’t be deleted. They’ve added a LSM that all operations go through AFAIK. You can’t disable it, even if you can prove you have physical access to the device.
But if you go through the UI that is not the case.
I still don’t know why you insist on using the CLI for this. Set up schedules to make snapshots and be done with it.
Now I agree that there should be a command flag or something that would prevent an immutable snapshot. But again use the tools given as intended. But I guess when the only tool you have is a hammer, everything is a nail.
Thanks. Yes no problem using the UI. I am new to QNAP and thought that basic zfs commands would work, since the appliance is based on that. There are degrees of CLI/customization. I think it’s readily obvious that if I start writing kernel drivers for it that I’m on my own, but zfs snapshot is a relatively basic command, like the “rm” command. I just didn’t expect QNAP to modify the behavior to not allow cleanup of it. Certainly zfs send/receive, which you can’t do in the UI, might have some use to some people, but I understand now that for those I should look at a different appliance.
While trying to unwind from this I was also surprised that I couldn’t export the pool and import it into a regular openzfs system. I didn’t expect that. It was like every path that I tried to “delete” a file was closed. I guess there is value in having all snapshots immutable, nevertheless if I can prove I have physical access to the device, it would be nice to have a way to remove them - like maintenance mode or pulling the drives out to a machine that doesn’t have the LSM.
Immutable snapshots is something new to QuTS Hero 6.0. So I would file a bug report and let QNAP know about this. Maybe it’s not their intention. I know in the UI when you create a snapshot that you have a choice about immutability. That said, there almost certainly has to be a CLI command for a mutable snapshot since the UI has to execute some kind of command in the OS.
As far as importing or exporting the pool into another ZFS system - that doesn’t surprise me that it doesn’t work. QNAP has a particular way of doing things and not every partition in QuTS Hero is a ZFS partition anyhow. It’s bit more complex under the hood than a standard Linux system.
The value QNAP brings with it is the OS, the feature set, the apps, etc. If you seriously want to create a bulk storage device based on Linux and drive it 100% via the CLI, then you will be far better off from a cost perspective to buy a box, put a RAID controller in it and have at it yourself. You can get an i9 Ultra PC for between $1500 and $2000. An i9 QNAP costs over $3000 and probably uses an i9 Mobile processor.
I don’t know if I should file a report because I can see how the current behavior is desirable. I just think a user could inadvertently walk into a situation, so maybe a warning would suffice. I think as you said the “immutability” is a bit confusing because it’s a new feature in 6.0. What I refer to is a snapshot that you create yourself, which can be immutable even in 5.x depending on how you create it, so maybe there should just be a warning. If I had known I wouldn’t have played with the commands. If you cat /sys/kernel/security/lsm, there’s a “qlsm” that sits in the way of any zfs operation, and will prevent a snapshot from being deleted on the CLI, so just let the user know before, rather than after…. Also maybe a “feature” that if you have physical access to the device, that you could temporarily disable qlsm would be handy. Nobody wants to “touch filename” and then not be able to “rm filename” - granted snapshots are a bit different than that, but similar idea.
In QuTS Hero 5.x, the snapshot would only be immutable if it was stored on an immutable volume, but as snapshots are not stored in normal volume space, I am not sure how you would do an immutable snapshot.
So few people likely use the CLI to create snapshots that they didn’t think to create options in the command line. I would file it as a bug/feature request…
I know Sophos firewalls have you "sign/awknolage’ a user agreement before they provide you a clear shell. Maybe QNAP could do the same From here on you FAFO Y/N
I still think that you should try qcli if you WANT to trigger snapshots via CLI
Yeah no problem with qcli_volumesnapshot because that creates them with all the other qnap stuff. It’s just zfs snapshot will leave permanent snapshots unless you delete the folder or reinit, so maybe it should have a warning, or QNAP can provide “some” way of deleting the manual snapshots. We can currently create and delete a manual dataset, just not snapshots.
Alternately if no warning, I think it would be handy, if it didn’t affect anything else, to disable the “qlsm” LSM in maintenance mode so they can be deleted. I understand the need to have permanent snaps to prevent ransomware, but if you can prove that you have physical access to the device, such as rebooting it in maintenance mode, you should be able to clean up manual snaps that can very easily be created accidentally from the CLI.
Thank you very much for your valuable feedback! Your input is extremely helpful for improving our product. We will forward your suggestions to the relevant departments for further evaluation. Thank you again for your support!