Troubleshooting ZFS File System Sharing Problems
Review the following share error conditions:
-
New shares or previous shares are not shared
-
Confirm the pool and the file system versions are current - If new shares are not shared by setting the
share.nfs
orshare.smb
property, then confirm that the pool version is 34 and the file system version is 6. -
Share must exist before NFS services start- NFS server services do not run until a file system is shared. Create the NFS share first and then attempt to access the share remotely.
-
System with existing shares was upgraded but shares are not available - A system with existing shares is upgraded but attempts to reshare the shares fail. The shares might not be shared because the
share.auto
property is disabled. Ifshare.auto
is set to off, only named shares are available, which enforces compatibility with earlier sharing syntax. The existing shares might look like this:$ zfs get share NAME PROPERTY VALUE SOURCE tank/data share name=data,path=/tank/data,prot=nfs local
-
Ensure that the
share.auto
property is enabled. If not, enable it.$ zfs get -r share.auto tank/data $ zfs set share.auto=on tank/data
-
Reshare the file system.
$ zfs set -r share.nfs=on tank/data
-
You might also need to remove named shares and recreate them before the preceding command is successful.
$ zfs list -t share -Ho name -r tank/data | xargs -n1 zfs destroy
-
If necessary, recreate the named shares.
$ zfs create -o share.nfs=on tank/data%share
-
-
Sharing properties including named shares are not included in snapshots - Share properties and
.zfs/shares
files are treated differently inzfs clone
andzfs send
operations. The.zfs/shares
files are included in snapshots and are preserved inzfs clone
andzfs send
operations. For a description of the behavior of properties duringzfs send
andzfs receive
operations, see Applying Different Property Values to a ZFS Snapshot Stream. After a clone operation, all files are from the pre-clone snapshot, whereas the properties are inherited from the clone's new position in the ZFS file system hierarchy. -
Named share request fails - If a request to create a named share fails because the share would conflict with the auto share, you may have to disable the
auto.share
property. -
Pool with shares was previously exported - When a pool is imported read-only, neither its properties nor its files can be modified so creating a new share fails. If the shares existed before the pool was exported, the existing sharing characteristics are used, if possible.
The following table identifies know share states and how to resolve them.
Share State | Description | Resolution |
---|---|---|
|
The share is invalid because it is internally inconsistent or because it conflicts with another share. |
Attempt to re-share the invalid share by using the following command: $ zfs share FS%share
Using this command displays an error message about which aspect of the share is failing validation. Correct this, then retry the share. |
|
The share is shared. |
None needed. |
|
The share is valid but is unshared. |
Use the |
|
The share is not yet validated. The file system that contains the share might not be in a shareable state. For example, it is not mounted or it is delegated to a zone other than the current zone. Alternatively, the ZFS properties representing the desired share have been created, but have not yet been validated as a legal share. |
Use the |