Make mount/share errors non-fatal for zfs create/clone

[ixhamza]

Motivation and Context

If zfs_mount_and_share() fails, the error propagates to zfs create/clone commands despite successful operation. If create/clone operations were successful, there's no point in making zfs_mount_and_share() failures fatal.

Description

How Has This Been Tested?

• CI to test.

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)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• 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.

[tonyhutter]

The error code seems valid here. The user is asking us to make a dataset/clone and then mount it, but we can't do the mount. If they had ZFS_PROP_CANMOUNT=off it would succeed.

Can you give a little more context for the change?

[ixhamza]

@tonyhutter - thank you for taking a look. For context, we are disabling NFS/SMB sharing at compile-time in TrueNAS, which makes zfs_mount_and_share() return an error, which is propogated to zfs create. After discussing internally with @amotin, unless we undo dataset creation, it seems wrong to return a non-zero exit code when the dataset was successfully created.

[amotin]

Also this is consistent with zfs set/inherit, where we don't report mount/share errors as long as the set/inherit themselves succeeded. Also note, that the mount/share errors are still reported to stderr, just not to return code.

[behlendorf]

My concern would be for any scripts that depend on the existing behavior. Even if it's not ideal. Have you considered using zfs create -u which creates the dataset but doesn't attempt the mount? That would provide you more control for any orchestration. I suppose the problem there is zfs clone doesn't support it.

[amotin]

@behlendorf In this case it is primarily not about mounting, but about sharing. The fact that sharing has failed, does not mean creation has failed. From all other purposes the dataset is created. Though even mounting failure does not necessary mean creation failure, unless we roll it back.

[behlendorf]

It'd be nice to have more granular zfs create|clone cli options for requesting mounting and sharing. But since we don't, I can see your point the return value should reflect result of the core operation requested.