Bug 219688 - [ZFS] zfs rename of mountpoint that is nfs shared leaves old NFS configuration active and unremoveable
Summary: [ZFS] zfs rename of mountpoint that is nfs shared leaves old NFS configuratio...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-31 18:19 UTC by Sean Bruno
Modified: 2017-05-31 21:22 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sean Bruno freebsd_committer freebsd_triage 2017-05-31 18:19:22 UTC
In the world of "yeah, don't do that", I was renaming a bunch of zfs mount points on my nfs server today.

'zfs rename mountpoint mountpoint.new'

These filesystems were NFS shared to host test machines for network style nfs booting.  After the zfs rename, the old entries still exist as indicated by the NFS server whining about them and their existence in /etc/zfs/exports.

This in itself may not be a bug, as the computer did what I told it to do.  However, the old sharenfs settings for the old mountpoint are now immutable.  Since the old mountpoints don't exist, the error checking to see if the mountpoints exist refuses to purge the nfs settings.

As a workaround, renaming the filesystems back to their old name allows me to purge the old nfs settings.

I had thought just creating any old filesystem with the old name would allow me to purge these settings, however it appears that the settings were set with "legacy" options of some kind as I receive the error:

cannot unshare 'zroot/tftpboot/netboot_sysdev06': legacy share
Comment 1 Sean Bruno freebsd_committer freebsd_triage 2017-05-31 18:21:45 UTC
Oh, trivial work around.

Create and then delete the old ZFS name.  This will cleanly purge the NFS settings.