Iker

The plugin doesn't provide that functionality... yet; however, if both filesystems are ZFS you can use zfs send | zfs recv commands. Those work at the block level, so they are very efficient and have linear performance no matter how many small files you have. If the destination filesystem is not a ZFS filesystem, you have to copy the files; there is no other way.

That's the idea with the ZnapZend integration.

Thanks for the report. There is already a new version with a fix for the bug.

Here is a new update with the following changelog: 2024.11.10 Fix - Style for Unraid 7 Add - Properties extraction for ZFS Volumes Fix - for folder listing corner cases For the next version, I'll try to integrate the plugin with ZnapZend, initially only to check backup plans for the datasets and, if everything goes well, also to create backup plans from the GUI.

I'm already working on fixing the styling for unraid 7 and a couple of improvements.

Not really, the plugin is compatible with the latest beta (At least in my test lab). If you find any problems or issues, please let me know, as I'm currently working on a new release.

The receiving pool must be upgraded to support the operation as the error states. Reference https://openzfs.github.io/openzfs-docs/man/master/8/zpool-upgrade.8.html

Don't worry; it's not a problem, but I'm not so sure what type of functionality you are asking for. Here is the thing: Unfortunately, Unraid doesn't support the native ZFS encryption scheme (yet); however, the LUKS encryptions work just fine; if you need extra privacy, it's possible, as you have suggested, to create additional datasets with different keys, but you have to unlock them manually. About the mount point listed as a folder, unfortunately, it is very hard to work in these little cases, as you can mount a dataset anywhere in the system, but I see what I can do.

Hi @mmm77, most of your assumptions are correct, Unraid can create an encrypted pool; this process encrypts the entire disk using LUKS so your data is always encrypted. On a note, currently, Unraid doesn't support ZFS native encryption for pools. Answering your question about data being encrypted twice, Yes, ZFS is not aware of the LUKS encryption, and in any case it allows you to have different keys/passphrases for different datasets, even if they are descendants of an encrypted one; moreover, ZFS allows you to have different settings for different datasets, that includes, compressions, mount points, etc; it's a very flexible system. I recommend you to read the following article https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/.

You need to enable "Destructive Mode" on the settings.

You can only create a clone in the same pool as the parent snapshot because a clone initially shares all its disk space with the original snapshot; the previous message from @Entxawp has the instructions for sending a snapshot to another pool; it can be within the same system or even remote.

That's a great idea, and I'll add it to my ever-growing set of features for the next major release. Please bear with me for a little while; I'm finishing other things, but I plan to implement all the pending fixes and new features by the end of the year, so stay tuned!

Hi @capduncan, indeed, the child dataset inherits the encryption key; a side effect is that when you unlock the father, you also unlock the child dataset and vice versa.

Thanks for the detailed report, let me try to replicate the issue so I can push an update with the fix.

Hi, you have to enable "Destructive Mode" on the settings page; then, you can enable the directory listing functionality for any dataset and convert the child folders to a dataset with a single click.

I tried the 6.13 beta that got changed to 7.0 beta; there were some changes in styles that are not yet definitive, I'm waiting for another RC version or beta to update all the styles as other changes may be introduced.

Hi, it's a matter of permissions, change them to 777 on the roof folder and add the -R flag for recursive operation and all should be good to go.

ZFS shows the very same information that you get from the regular "zpool" and "zfs" commands; for example, here is my hddmain pool reported via zpool list vs unraid: But why is that? There are two factors: Unraid shows the units using SI (TeraBytes, Gigabytes, etc.) instead of IEC (Tibibytes, Gibibytes, etc.); zfs natively uses IEC units, so there is a discrepancy. The larger the pool, the larger the difference. Unraid shows you the usable space on the GUI interface reported from the filesystem, but that's not the same information reported by ZFS; in your case, I'm guessing a RAIDZ-1 config, so you get 2TB * (3-p) with p = 1 disk for redundancy; in practical terms, that means 4 TB of usable space; but at the pool level that's not what gets reported, instead ZFS reports 6 TB (Convert it to IEC TBi and you get your 5.5 TB) of total space because that's the pool topology, not the one showed at the filesystem level. Now, at the dataset level (zfs list) ZFS reports the actual numbers you want to know because that config applies to the filesystem level, how much space you can use, excluding the parity, slop space, snapshots, etc. I hope this sheds some light on why the numbers are different and why I keep them as they are (Because I think they are useful!). PS: BTW, I noticed the plugin is not correctly appending the Pool stats IEC (TiB); I'll fix that in an upcoming release.

It stays alive for a little while after the main tab closes, but it shouldn't take more than a minute to completely shutdown. Unraid takes care of that automatically as it's executed as an nchan process (WebSocket Unraid implementation for efficiently pulling information and execute background jobs).

You can modify the config by editing the file "/boot/config/plugins/zfs.master/zfs.master.cfg" the "refresh_interval" is in seconds; you can modify it to any value you like. On the other hand, keep in mind that the plugin doesn't update the information or perform any action unless you open the tab on the main tab, and you also have the "no refresh" option, so you can refresh the information at will by clicking the refresh button, that may be a better fit for your use case.

As you have pointed out, the only change since the last time you were "problems-free" was the addition of a new property to the list pulled from the pools. That's a really simple change, and I don't believe it could be the cause of the problems that you are facing. It's tricky to replicate on my side (I already try, and it works just fine). From my perspective, it might be something related to the USB pool, or even worse; it might signal a dying disk with lots of command timeouts, slow spin-up times, or other errors; please try to execute the zfs list command that I mentioned to you and report back, if the error persists, I can send you a link for installing the plugin without the last commit and test a little bit further, so we can check if that new property is the culprit, if that turns out to be the case I will revert the changes on the main branch and everything returns to normal.

Hi, you can find more details in the following PR https://github.com/IkerSaint/ZFS-Master-Unraid/pull/15.

Hi, there is an indicator for the last successful refresh, it includes the date and hour up to the second, if that doesn't change, it means that it's not refreshing, also, please give it 30 seconds to pickup the new config and check again if it's working as expected.

"/docker/.*" works for me, but the "docker" dataset is still showing, I think that's the best you can achieve with the current limitations. (Give it 30 seconds to pickup the config change) I don't know if that is related directly to the plugin or if the pools over USB HDD are extremely slow when dealing with random reads. You can try the following command and check if it's slow: zfs list -r -t snapshot -o name,creation backuppool If that's the case, there is nothing to do on my side, as it's something inherent to the pool.

It's working, or at least as it has been working for a while. Datasets are not entirely hidden if you use ".*" termination, but his children are not listed, as it's helpful to know how much space they take and what their properties are. If you want to get rid entirely of the dataset on the main interface, use "/docker", but be aware that it can match multiple datasets outside of the ones you mentioned.