NAS-123279 / 23.10 / Improve the handling of mountpoint, sharesmb and sharenfs properties

[usaleem-ix]

Motivation and Context

There are some inconsistencies in the handling of mountpoint, sharesmb and sharenfs
properties.

If mountpoint property is set when dataset is unmounted, this would update the mountpoint
property. The mountpoint could be valid or invalid in this case. Setting the mountpoint property
would result in success and dataset would still be unmounted here.

On the other hand, if dataset is mounted and mountpoint property is updated to something
invalid where mount cannot be successful, for example, setting the mountpoint inside a readonly
directory. This would unmount the dataset, set the mountpoint property to requested value and
tries to mount the dataset. The mount operation returns error and this error is treated as overall
failure of setting the property while the property is actually set.

For sharesmb and sharenfs properties, the status of setting the property is tied with whether
we succeed to share the dataset or not. In case sharing the dataset is not successful, this is
treated as overall failure of setting the property. In this case, if we check the property after the
failure, it is set to on.

For sharenfs property, if access list is provided, the syntax errors in access list/host addresses
are not validated until after setting the property during postfix phase while trying to share the
dataset. This is not correct, since the property has already been set when we reach there.

For TrueNAS SCALE, zfs-share.service executes zfs share -a on every boot and fails to
share over SMB or NFS if sharesmb and/or sharenfs are set, as we are handling shares in
middleware differently.

Description

For mountpoint property, to make the behavior consistent in case dataset is mounted or
unmounted, we should try to mount the dataset whenever mountpoint property is updated. This
would result in mounting the datasets if canmount property is set to on, regardless if the dataset
was previously unmounted.

The failure in mount operation while setting the mountpoint property should not be treated as
failure, since the property is actually set now to user requested value.

Similarly, for sharenfs and sharesmb properties, the status of setting the share properties
should not be returned as failure, when we fail to share the dataset.

For sharenfs property, syntax errors in access list/host addresses are validated while validating
the property list, before setting the property and failure is returned to user in this case when there
are errors in access list.

zfs-share.service is now disabled since middleware is responsible for sharing over SMB and
NFS.

How Has This Been Tested?

Manually tested by setting the properties and ran ZTS.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[bugclerk]

Jira URL: https://ixsystems.atlassian.net/browse/NAS-123279

[bugclerk]

Not updating JIRA ticket https://ixsystems.atlassian.net/browse/NAS-123279 target versions as no JIRA version corresponds to this PR