In QuTS 5.x it is possible to create a snapshot as uid 0 outside of the UI, however as soon as you do that, you can’t delete the snapshot.
Other than calling technical support and having them spend time cleaning it up, is there any procedure to clear whatever is preventing the snapshot from being deleted. It seems to me that if you let the user create the snapshot in the first place, they should be able to delete it if it is not WORM.
It’s not just snapshots. I am just giving a simplified example. When you have ssh access to the device, you can do any number of operations that results in a situation where the kernel or something vetos destruction. I didn’t have time to look at all the implementation details to QNAP’s zfs, but one point I find confusing is that you “let” the user use the basic zfs tools, and this very quickly results in a situation where they are stuck. I’ve tried many ways to get it to destory using the normal zfs tools and I can’t.
There are times, when it would be “nice” to use zfs send/receive locally (I wrote about this in another post). That too will result in not being able to destroy the target of the receive. Maybe QNAP could put a warning not to use things like snapshot, send, receive, etc… I do have a ticket open but asked here to see if anyone knew. I guess I could always pull the disk and delete it from a normal zfs system.
Well I cannot speak for QNAP here, but if they did cook their own ZFS soup, they are doomed either way
Prevent users from executing commands = Outcry
Allow users to execute commands, that fail due to some special sauce they use = Outcry
I would say more than 95% of all QNAP users will never even look into these ‘under the hood’ details, if you fall in those (less than) 5%, you could either use qcli or just use a different distro on the hardware (e.g. TrueNAS)
It is something specifically with snapshots. Even if you create a pool completely out of the UI, any once a snap is created you can’t delete anything. Yet if you just create a pool, then you can delete it without any problem as long as it does not have any snapshots. Can QNAP comment on this behavior and why even allow a snapshot that is just going to permanently take up storage and can not be deleted?
I’m trying to understand why you are doing this all in command line when you can do it all in the UI. There may be additional commands or things you would need to run in order to do what you want to do. All that is taken care of automatically in the UI. It’s highly likely there is something you are missing.
“It’s not just snapshots. I am just giving a simplified example.” I might want to use rsync.net Cloud Storage for Offsite Backups , or I might want to zsend/receive locally, such as making a recursive copy of my raidz2 to a large single drive (locally). The later is NOT supported in the UI, and will also result in artifacts you can’t delete. But it’s a more general question above that: why give access to the zfs utilities if you can’t use them. Either warn the enduser clearly not to use them (like you seem to be), or provide some sort of technote on how to clean up any QNAP-related enhancements to zfs that prevent it from working normally. When I bought a QNAP I was impressed that they were using zfs, and I didn’t see a whole lot about it being “restricted” in use from the command line.
I don’t know, maybe people think I am weird, but to me the whole reason why you have a NAS is to make things simpler.
It would be much lower cost and much more compute horsepower to simply buy a solid i9 ultra computer, put Linux on it, add a raid card and GPU and you are off and running. Now load it up with drives and you have a do it yourself NAS. All the command line stuff you want. And you spend a lot less money. Probably somewhere between $1000 and $1500 less.
The whole point of a NAS to me is to use the UI and the interfaces provided so I don’t have to worry about stuff working on the command line.
Now, I don’t disagree with your point that if QNAP has the ZFS utilities there, they should work. I am just saying maybe there’s another step in there that you are missing.
Just to be clear, the snapshots would under the folder in the UI not the volume. zpool1/zfs21 would map to a folder, so in the UI if you delete that folder, then you will delete all the snapshots related to it. The way the UI deletes the folder it has extra privs beyond what you would normally have even with uid 0 at the CLI. However to “fix” it that way means you would lose all the data in that folder, so you should back it up first. This is the fundamental problem with the way they’ve implemented things, in that if anybody or “anything” makes a mistake, you have to delete and start over.
Hi, @NA9D my problem was, the UI and reality went out of sync.
The snapshot was NOT visible within the UI, but was there when checking with “zfs list -t snapshot”.
The snapshosts consumed about 60% of the storage capacity and lead to 100% fillup (which known issue for problems )
But I was unable to fix it via UI nor via CLI.
I opened a ticket and support provided several times cli commands like “zfs destroy …” which stoppend with “Permission denied”.
They fetched 2nd level with remoteaccess within the helpdesk app.
The support did something, I don’t know, but