Mounting and Sharing ZFS File Systems
This section describes how mount points and shared file systems are managed in
ZFS.
Managing ZFS Mount Points
By default, all ZFS file systems are mounted by ZFS at boot
by using SMF's svc://system/filesystem/local service. File systems are mounted under /path, where path is the
name of the file system.
You can override the default mount point by setting the mountpoint property
to a specific path by using the zfs set command. ZFS automatically creates this
mount point, if needed, and automatically mounts this file system when the zfs mount -a
command is invoked, without requiring you to edit the /etc/vfstab file.
The mountpoint property is inherited. For example, if pool/home has mountpoint set to
/export/stuff, then pool/home/user inherits /export/stuff/user for its mountpoint property.
The mountpoint property can be set to none to prevent the file system
from being mounted. In addition, the canmount property is available for determining whether
a file system can be mounted. For more information about the canmount property,
see The canmount Property.
If desired, file systems can also be explicitly managed through legacy mount interfaces
by setting the mountpoint property to legacy by using zfs set. Doing so
prevents ZFS from automatically mounting and managing this file system. Legacy tools including the
mount and umount commands, and the /etc/vfstab file must be used instead.
For more information about legacy mounts, see Legacy Mount Points.
When changing mount point management strategies, the following behaviors apply:
Automatic Mount Points
When changing from legacy or none, ZFS automatically mounts the file system.
If ZFS is currently managing the file system but it is currently unmounted, and the mountpoint property is changed, the file system remains unmounted.
You can also set the default mount point for the root dataset
at creation time by using zpool create's -m option. For more information about creating pools,
see Creating a ZFS Storage Pool.
Any dataset whose mountpoint property is not legacy is managed by ZFS.
In the following example, a dataset is created whose mount point is automatically
managed by ZFS.
# zfs create pool/filesystem
# zfs get mountpoint pool/filesystem
NAME PROPERTY VALUE SOURCE
pool/filesystem mountpoint /pool/filesystem default
# zfs get mounted pool/filesystem
NAME PROPERTY VALUE SOURCE
pool/filesystem mounted yes -
You can also explicitly set the mountpoint property as shown in the following
example:
# zfs set mountpoint=/mnt pool/filesystem
# zfs get mountpoint pool/filesystem
NAME PROPERTY VALUE SOURCE
pool/filesystem mountpoint /mnt local
# zfs get mounted pool/filesystem
NAME PROPERTY VALUE SOURCE
pool/filesystem mounted yes -
When the mountpoint property is changed, the file system is automatically unmounted from
the old mount point and remounted to the new mount point. Mount point
directories are created as needed. If ZFS is unable to unmount a file
system due to it being active, an error is reported and a forced
manual unmount is necessary.
Legacy Mount Points
You can manage ZFS file systems with legacy tools by setting the
mountpoint property to legacy. Legacy file systems must be managed through the mount
and umount commands and the /etc/vfstab file. ZFS does not automatically mount legacy file
systems on boot, and the ZFS mount and umount command do not
operate on datasets of this type. The following examples show how to set
up and manage a ZFS dataset in legacy mode:
# zfs set mountpoint=legacy tank/home/eschrock
# mount -F zfs tank/home/eschrock /mnt
In addition, you must mount them by creating entries in the /etc/vfstab file. Otherwise,
the system/filesystem/local service enters maintenance mode when the system boots.
To automatically mount a legacy file system on boot, you must add
an entry to the /etc/vfstab file. The following example shows what the entry in
the /etc/vfstab file might look like:
#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options
#
tank/home/eschrock - /mnt zfs - yes -
Note that the device to fsck and fsck pass entries are set to -. This syntax
is because the fsck command is not applicable to ZFS file systems. For
more information regarding data integrity and the lack of need for fsck in
ZFS, see Transactional Semantics.
Mounting ZFS File Systems
ZFS automatically mounts file systems when file systems are created or when the
system boots. Use of the zfs mount command is necessary only when changing mount
options or explicitly mounting or unmounting file systems.
The zfs mount command with no arguments shows all currently mounted file systems that
are managed by ZFS. Legacy managed mount points are not displayed. For example:
# zfs mount
tank /tank
tank/home /tank/home
tank/home/bonwick /tank/home/bonwick
tank/ws /tank/ws
You can use the -a option to mount all ZFS managed file systems.
Legacy managed file systems are not mounted. For example:
# zfs mount -a
By default, ZFS does not allow mounting on top of a nonempty
directory. To force a mount on top of a nonempty directory, you must
use the -O option. For example:
# zfs mount tank/home/lalt
cannot mount '/export/home/lalt': directory is not empty
use legacy mountpoint to allow this behavior, or use the -O flag
# zfs mount -O tank/home/lalt
Legacy mount points must be managed through legacy tools. An attempt to use
ZFS tools results in an error. For example:
# zfs mount pool/home/billm
cannot mount 'pool/home/billm': legacy mountpoint
use mount(1M) to mount this filesystem
# mount -F zfs tank/home/billm
When a file system is mounted, it uses a set of mount
options based on the property values associated with the dataset. The correlation
between properties and mount options is as follows:
- Property
Mount Options
- devices
devices/nodevices
- exec
exec/noexec
- readonly
ro/rw
- setuid
setuid/nosetuid
The mount option nosuid is an alias for nodevices,nosetuid.
You can use the NFSv4 mirror mount features to help you better manage
NFS-mounted ZFS home directories. For a description of mirror mounts, see ZFS and File System Mirror Mounts.
Using Temporary Mount Properties
If any of the above options are set explicitly by using the-o
option with the zfs mount command, the associated property value is temporarily overridden. These property
values are reported as temporary by the zfs get command and revert back
to their original settings when the file system is unmounted. If a property
value is changed while the dataset is mounted, the change takes effect immediately, overriding
any temporary setting.
In the following example, the read-only mount option is temporarily set on the
tank/home/perrin file system:
# zfs mount -o ro tank/home/perrin
In this example, the file system is assumed to be unmounted. To
temporarily change a property on a file system that is currently mounted, you
must use the special remount option. In the following example, the atime property
is temporarily changed to off for a file system that is currently mounted:
# zfs mount -o remount,noatime tank/home/perrin
# zfs get atime tank/home/perrin
NAME PROPERTY VALUE SOURCE
tank/home/perrin atime off temporary
For more information about the zfs mount command, see zfs(1M).
Unmounting ZFS File Systems
You can unmount file systems by using the zfs unmount subcommand. The unmount command
can take either the mount point or the file system name as arguments.
In the following example, a file system is unmounted by file system name:
# zfs unmount tank/home/tabriz
In the following example, the file system is unmounted by mount point:
# zfs unmount /export/home/tabriz
The unmount command fails if the file system is active or busy. To
forceably unmount a file system, you can use the -f option. Be cautious
when forceably unmounting a file system, if its contents are actively being used.
Unpredictable application behavior can result.
# zfs unmount tank/home/eschrock
cannot unmount '/export/home/eschrock': Device busy
# zfs unmount -f tank/home/eschrock
To provide for backwards compatibility, the legacy umount command can be used to
unmount ZFS file systems. For example:
# umount /export/home/bob
For more information about the zfs umount command, see zfs(1M).
Sharing and Unsharing ZFS File Systems
Similar to mount points, ZFS can automatically share file systems by using the
sharenfs property. Using this method, you do not have to modify the /etc/dfs/dfstab
file when a new file system is added. The sharenfs property is a
comma-separated list of options to pass to the share command. The special value on
is an alias for the default share options, which are read/write permissions for
anyone. The special value off indicates that the file system is not
managed by ZFS and can be shared through traditional means, such as the
/etc/dfs/dfstab file. All file systems whose sharenfs property is not off are shared
during boot.
Controlling Share Semantics
By default, all file systems are unshared. To share a new file
system, use zfs set syntax similar to the following:
# zfs set sharenfs=on tank/home/eschrock
The property is inherited, and file systems are automatically shared on creation if
their inherited property is not off. For example:
# zfs set sharenfs=on tank/home
# zfs create tank/home/bricker
# zfs create tank/home/tabriz
# zfs set sharenfs=ro tank/home/tabriz
Both tank/home/bricker and tank/home/tabriz are initially shared writable because they inherit the sharenfs
property from tank/home. Once the property is set to ro (readonly), tank/home/tabriz is
shared read-only regardless of the sharenfs property that is set for tank/home.
Unsharing ZFS File Systems
While most file systems are automatically shared and unshared during boot, creation, and
destruction, file systems sometimes need to be explicitly unshared. To do so, use
the zfs unshare command. For example:
# zfs unshare tank/home/tabriz
This command unshares the tank/home/tabriz file system. To unshare all ZFS file systems
on the system, you need to use the -a option.
# zfs unshare -a
Sharing ZFS File Systems
Most of the time the automatic behavior of ZFS, sharing on boot
and creation, is sufficient for normal operation. If, for some reason, you unshare a
file system, you can share it again by using the zfs share command. For
example:
# zfs share tank/home/tabriz
You can also share all ZFS file systems on the system by
using the -a option.
# zfs share -a
Legacy Share Behavior
If the sharenfs property is off, then ZFS does not attempt to share
or unshare the file system at any time. This setting enables you to
administer through traditional means such as the /etc/dfs/dfstab file.
Unlike the traditional mount command, the traditional share and unshare commands can
still function on ZFS file systems. As a result, you can manually share
a file system with options that are different from the settings of the
sharenfs property. This administrative model is discouraged. Choose to either manage NFS shares completely
through ZFS or completely through the /etc/dfs/dfstab file. The ZFS administrative model is
designed to be simpler and less work than the traditional model. However, in
some cases, you might still want to control file system sharing behavior through
the familiar model.
Sharing ZFS Files in a Solaris CIFS Environment
The sharesmb property is provided to share ZFS files by using the Solaris
CIFS software product. When this property is set on a ZFS file system,
these shares are visible to CIFS client systems. For more information about using
the CIFS software product, see the System Administration Guide: Windows Interoperability.
For a detailed description of the sharesmb property, see The sharesmb Property.
Example 5-1 Example—Sharing ZFS File Systems (
sharesmb)
In this example, a ZFS file system sandbox/fs1 is created and shared with
the sharesmb property. If necessary, enable the SMB services.
# svcadm enable -r smb/server
svcadm: svc:/milestone/network depends on svc:/network/physical, which has multiple instances.
# svcs | grep smb
online 10:47:15 svc:/network/smb/server:default
# zpool create sandbox mirror c0t2d0 c0t4d0
# zfs create sandbox/fs1
# zfs set sharesmb=on sandbox/fs1
The sharesmb property is set for sandbox/fs1 and its descendents.
Verify that the file system was shared. For example:
# sharemgr show -vp
default nfs=()
zfs nfs=()
zfs/sandbox/fs1 smb=()
sandbox_fs1=/sandbox/fs1A default SMB resource name, sandbox_fs1, is assigned automatically.
In this example, another file system is created, sandbox/fs2, and shared with a
resource name, myshare.
# zfs create sandbox/fs2
# zfs set sharesmb=name=myshare sandbox/fs2
# sharemgr show -vp
default nfs=()
zfs nfs=()
zfs/sandbox/fs1 smb=()
sandbox_fs1=/sandbox/fs1
zfs/sandbox/fs2 smb=()
myshare=/sandbox/fs2The sandbox/fs2/fs2_sub1 file system is created and is automatically shared. The inherited resource
name is myshare_fs2_sub1.
# zfs create sandbox/fs2/fs2_sub1
# sharemgr show -vp
default nfs=()
zfs nfs=()
zfs/sandbox/fs1 smb=()
sandbox_fs1=/sandbox/fs1
zfs/sandbox/fs2 smb=()
myshare=/sandbox/fs2
myshare_fs2_sub1=/sandbox/fs2/fs2_sub1Disable SMB sharing for sandbox/fs2 and its descendents.
# zfs set sharesmb=off sandbox/fs2
# sharemgr show -vp
default nfs=()
zfs nfs=()
zfs/sandbox/fs1 smb=()
sandbox_fs1=/sandbox/fs1In this example, the sharesmb property is set on the pool's top-level file
system. The descendent file systems are automatically shared.
# zpool create sandbox mirror c0t2d0 c0t4d0
# zfs set sharesmb=on sandbox
# zfs create sandbox/fs1
# zfs create sandbox/fs2
The top-level file system has a resource name of sandbox, but the descendents
have their dataset name appended to the resource name.
# sharemgr show -vp
default nfs=()
zfs nfs=()
zfs/sandbox smb=()
sandbox=/sandbox
sandbox_fs1=/sandbox/fs1 smb=()
sandbox_fs2=/sandbox/fs2 smb=()
