ZFS settings

To achieve a close approximation of posix (Linux) permissions, I use the following on the CLI.

(Where ZFS1 is replaced with the name of your pool.)

zfs set aclinherit=passthrough ZFS1
zfs set acltype=posixacl ZFS1
zfs set xattr=sa ZFS1
zfs set compression=lz4 ZFS1

(You've already set the last attribute for compression. It's not required, but provided for readers who may want to do the same.)

Unfortunately, the above pool attributes need to be applied to the pool before you move data into it. (They only apply to data added to the pool, after they are applied.)
Otherwise, your files will have mixed attributes which, from a permissions perspective, can cause odd issues.
__________________________________________________________

Quote from savellm

Lastly I cannot delete these snapshots either

This is not normal behavior.

Quote from savellm

And here you can see the one pool is doing snapshots and the other isnt.

The pool that's not deleting snapshots, was it the second pool created?
_________________________________________________________

Out of curiosity, why do you have two pools?
You said this a new setup so I'm guessing you have backup?

I get the reason for two pools now. I asked because ZFS works with block devices and it seems that there are those who will partition drives, without considering the effects.
_____________________________________________

There's a thread on the forum regarding installation and running ZFS (which I can't seem to find at the moment ).
The thread has gone long and would require a lot of reading so I'll give you a short course of action to consider.

Since you're not committed yet and it appears that your data store will be huge:

If it was me I would;

- rebuild.
- get everything up-to-date and reboot.
- install OMVExtra's and enable the testing repo, and run "apt clean"
Here, you'll be at a decision point. In the OMVExtras Kernel Tab, you'll find the Proxmox Kernel. The Proxmox kernel already has the ZFS header modules built and compiled into the kernel. If you switch to the Proxmox kernel there's nothing to go wrong when the ZFS plugin is added.

**On the other hand, since you're having difficulty going the Proxmox Kernel route, maybe going with the standard back ports kernel might be the way to go. I'm using kernel 4.19 with no problems.**

- install the ZFS plugin
If you didn't go with the proxmox kernel, creating the header modules will awhile - get up and walk away until it completes. There may be a few errors during the install. Generally speaking, if the plugin shows up, it's good. And while it may not be necessary at this point, I'd reboot.

- create a pool
- run the commands posted above for correct permissions
- create at least one child filesystem on the pool. (Settings on the parent are passed through to the file system. It's good practice to store data in a filesystem versus just using the parent pool which is similar to dumping data at the root of a drive.)
- add some data
- test snapshots, etc.

- create your second pool, etc.

In the bottom line, you should be able to take a snapshot and delete a snapshot in the GUI.
____________________________________________

Let us know if you have questions and/or how it went.

Tagging @hoppel118 and @ellnic who are ZFS users and may want to chime in.

Quote from savellm

Mate

Are you an Australian ?

Quote from savellm

What do you mean by back ports kernel?

The current OMV kernel (4.19) is a Debian back ports kernel. Proxmox is based on Ubuntu 4.15 (I think). Back ports kernels are the standard in OMV. They run the latest hardware with fewer issues. As an example, I think the "standard" kernel for Debian 9 (stretch) is 4.9.

Quote from savellm

As in just leave the kernel that comes with OMV and install ZFS and let it compile the headers?

Sure. That's what I'm using. I certainly won't hurt to try it. But if you go this route and everything works as it should, put a hold on the kernel so there are no automatic upgrades. (OMVExtra's has a provision for this.)

Arguments could be made for going either way.

As an example, using OMV's standard kernel (what I'm currently doing) comes with a risk. Since it is a backports kernel, closer to the cutting edge, the next kernel upgrade may have a problem or issue with current ZOL (ZFS on Linux) packages. And easy way to remove this risk is to set the working kernel as "default" (or put a hold on it) and check to insure compatibility before upgrading to a new kernel. Also, if an upgrade proves to a problem for ZFS, dropping back to the old kernel works. That's easy enough to do in OMVExtras. BTW, the current kernel 4.19 works fine with current ZFS packages. If your install works fine, put a hold on the kernel, done.

The Proxmox kernel comes with precompiled ZFS modules, in a Ubuntu kernel, so ZFS incompatibility would never be a risk. On the other hand updates are slightly different for this kernel and (I'm not sure about this) there might be other slight userland differences. Nothing truly significant for the NAS use case (OMV) in any case.

Either way it's about knowing the differences and how to deal with them.

**Edit**
A second fall back that I use is operating system backup. With full OS backup, even if some upgrade (the kernel or other) goes south, I can fall back to a known good working state with backup. I use USB thumbdrives to boot - cloneing them for backup is real easy. Restorations take about 3 minutes.

While you wouldn't need to do it right off the bat, if I were you, I'd seriously consider it. There's a huge difference between taking a occasional manual snapshot and automating them.

I use zfs-auto-snapshot in the way it's defined in the How-To, on 2 servers. Read over the notes at the end (note 3) for advice on high turnover filesystems. In such cases, I've turned off all but daily snapshots, maintaining a history of 31 days. For the remainder of my largely static file systems, I've turned off "frequent", "hourly" and "weekly" just to cut down on snapshot clutter.

While there's a more sophisticated approach (Znapzend), I've had zero issues using zfs-auto-snapshot. Most of the use cases on this forum, with largely static data, would work fine with zfs-auto-snapshot.
___________________

After you get all of this working, give serious thought to backing up your OS. (It would be a shame to lose a good, working, configuration.)

If you're interested in booting from USB thumbdrives, and cloning them for OS backup, take a look at this -> guide.

@savellm - I see someone has decided to make an introduction. I didn't read the entire novelette written above - I never do. Some, very few at a guess, want to get on the command line for everything and turn every relatively minor clean up or recovery operation into a dissertation. OMV was not created for that sort of user.

On a rebuild: If you want to get on the command line and try to figure out what happened and "maybe" figure it out (or maybe miss something?) all I can say is good luck. How long that might take is unknown - versus investing 15 to 20 minutes in a rebuild where the outcome is a bit more trustworthy. Which would be shorter? I'll leave that to you.

Before taking anything seriously, note that there are those who believe the entire world is "stupid", "dumb", "don't know what they're doing", etc., and will scream it to all who will listen. As an prime example, take a look at this post, and maybe read through the thread to get some perspective. I'm forced to agree with the Armbian forum moderators link to very good advice. Yes, unfortunately, every village has one.

Further, some have known anger management issues. In such cases, where anger takes over, common sense and logic goes out the window. This is well known - nothing new.

If you're still interested in running ZFS, we can take this into a private conversation. That's in the upper left hand area, on this page. I'll lend you a hand, but I know from experience that this thread will become so polluted and confusing, it would be pointless to continue it.

Regards.

Quote from savellm

I created one docker with netdata and just let it run overnight went to bed. Woke up this morning and see: i.imgur.com/Bc03K6v.png
I didnt create any manual snapshots or anything, this was all auto, is this right?

After taking this matter into a PM, (where interference was eliminated) the following was found.
It may be of use to ZFS users who run into the same problem.

The issue occurs with Docker containers are created in a ZFS pool. The result is, the ZFS pool lists what appears to be a series of child "clones" and a sub-filesystem or two, under the filesystem where Docker containers are stored. Since the (Docker) container is in use, these clones can't be deleted or otherwise removed.

The fix is easy enough. Stop and delete all containers, Docker images, and relocate the Docker storage directory to the default location (the boot drive) or another non-ZFS drive dedicated to utility uses.

There's a -> ZFS driver for Dockers for those who may want to set it up. On the other hand, the setup notes indicate that this driver may not be suitable for the typical OMV home user.