failure to create SMB share (POSIX vs NFSV4)

[mervincm]

I am trying to create a share (called ssdpool2 at /mnt/ssdpool2) and it fails with an error

ACL type mismatch with child mountpoint at /mnt/ssdpool2/ix-applications/docker/zfs/graph/45f9bed5ab29495db71b0c6a612a496e7da5b4ccbe44388ffc69bb7030b9c2d6: ssdpool2 - NFSV4, ssdpool2/ix-applications/docker/45f9bed5ab29495db71b0c6a612a496e7da5b4ccbe44388ffc69bb7030b9c2d6 - POSIX

This seems to complain that I have subfolders differing permission schemes POSIX vs NFSV4

Is this an unsupported situation? Recently unsupported?

 

[mervincm]

Usually when a post gets no traction it is because it is something obvious that I missed, and folks feel I am wasting their time, or I didn't include enough info for someone to help. Do I need to add more detail or is it obvious and I need to keep googling :)

 

[mervincm]

Any fresh eyes? Is this new expected behaviour, a sign of a corrupted installation that needs.a complete rebuild? I have tried searching but I have not found a solution. I would like to upgrade to bluefin but am concerned it may fail related to this strange behaviour.

 

[anodos]

Any fresh eyes? Is this new expected behaviour, a sign of a corrupted installation that needs.a complete rebuild? I have tried searching but I have not found a solution. I would like to upgrade to bluefin but am concerned it may fail related to this strange behaviour.

This is due to extra validation being added because of user bug reports where ZFS dataset property mismatches on nested datasets within SMB shares led to poorly-defined behavior.

Generally speaking, sharing out root of a zpool has always been discouraged as bad practice (create a dataset and share it out), and exposing your ix-applications dataset is definitely a potential recipe for future problems with your apps.

 

[Daisuke]

Generally speaking, sharing out root of a zpool has always been discouraged as bad practice

I highlighted this issue into my checklist thread, should help others.

 

[mervincm]

This is due to extra validation being added because of user bug reports where ZFS dataset property mismatches on nested datasets within SMB shares led to poorly-defined behavior.

Generally speaking, sharing out root of a zpool has always been discouraged as bad practice (create a dataset and share it out), and exposing your ix-applications dataset is definitely a potential recipe for future problems with your apps.

I really appreciate you taking the time to point this out. I can live with not being able to share the root of a pool quite easily, now that I know it is a bad practice and intentional.

 

[anodos]

I really appreciate you taking the time to point this out. I can live with not being able to share the root of a pool quite easily, now that I know it is a bad practice and intentional.

Right, when you share out the root of a pool in a work setting you potentially lose quite a bit of flexibility reconfiguring your server. Business needs can change. It's not altogether uncommon for a small operation to start up with just a "shared drive" that an administrator decides to configure as /mnt/tank.

Then at some point it's decided that marketing should really have its own share with a different permissions configuration. At this point the admin has to potentially take a maintenance window to shift around data into a new child dataset, whereas if he or she had initially created a dataset 'tank/share', they could just create tank/marketing and create a new share.

Separating our your data into separate datasets allows for different snapshot policies, permissions, etc, etc. It ends up being more flexible and less work in the long-run.