In general, you can force the unmount with the "-f" flag. As to your specific question of changing the mountpoint to somewhere that it can't currently be mounted, it should set the mountpoint property but not remount it. E.g.:
# zfs set mountpoint=/ rpool/test cannot mount '/': directory is not empty property may be set but unable to remount filesystem # zfs get mountpoint rpool/test NAME PROPERTY VALUE SOURCE rpool/test mountpoint / local If for some reason that isn't working for you, you could try "zfs set canmount=noauto", possibly combined with changing it back to canmount=on after changing the mountpoint. The the zfs(1m) manpage's description of the canmount property for more details. --matt On Fri, Nov 9, 2012 at 8:47 AM, Jim Klimov <jimkli...@cos.ru> wrote: > There are times when ZFS options can not be applied at the moment, > i.e. changing desired mountpoints of active filesystems (or setting > a mountpoint over a filesystem location that is currently not empty). > > Such attempts now bail out with messages like: > cannot unmount '/var/adm': Device busy > cannot mount '/export': directory is not empty > > and such. > > Is it possible to force the new values to be saved into ZFS dataset > properties, so they do take effect upon next pool import? > > I currently work around the harder of such situations with a reboot > into a different boot environment or even into a livecd/failsafe, > just so that the needed datasets or paths won't be "busy" and so I > can set, verify and apply these mountpoint values. This is not a > convenient way to do things :) > > Thanks, > //Jim Klimov > > ______________________________**_________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/**mailman/listinfo/zfs-discuss<http://mail.opensolaris.org/mailman/listinfo/zfs-discuss> >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
