排除 ZFS 文件系统共享问题

检查以下共享错误情况：

• 新共享或之前的共享未共享

  • 确认池和文件系统版本为新版本－如果通过设置 share.nfs 或 share.smb 属性未共享新共享，则确认池版本是否为 34，文件系统版本是否为 6。

  • 在 NFS 服务启动前共享必须已存在－在共享文件系统后 NFS 服务器服务才会运行。首先创建 NFS 共享，然后尝试远程访问共享。

  • 升级了存在共享的系统，但共享不可用－升级了存在共享的系统，但是尝试重新共享这些共享时失败。这些共享无法共享，因为禁用了 share.auto 属性。如果 share.auto 设置为 off，则只能使用命名共享，以强制与早期的共享语法兼容。现有共享可能类似于：

    # zfs get share
    NAME                        PROPERTY  VALUE  SOURCE
    tank/data                   share     name=data,path=/tank/data,prot=nfs  local

  1. 确保启用了 share.auto 属性。如果未启用，启用该属性。

     # zfs get -r share.auto tank/data
     # zfs set share.auto=on tank/data

  2. 重新共享文件系统。

     # zfs set -r share.nfs=on tank/data

  3. 您可能还需要删除命名共享，然后重新创建，这样前面的命令才能成功运行。

     # zfs list -t share -Ho name -r tank/data | xargs -n1 zfs destroy

  4. 如果必要，重新创建命名共享。

     # zfs create -o share.nfs=on tank/data%share

• 快照中未包含包括命名共享的共享属性－在 zfs clone 和 zfs send 操作中，共享属性和 .zfs/shares 文件的处理方式不同。.zfs/shares 文件包含在快照中并保留在 zfs clone 和 zfs send 操作。有关 zfs send 和 zfs receive 操作期间的属性行为的说明，请参见向 ZFS 快照流应用不同的属性值。完成克隆操作之后，所有文件均来自上一克隆快照，而属性将继承自克隆在 ZFS 文件系统分层结构中的新位置。

• 命名共享请求失败－如果创建命名共享的请求由于此共享与自动共享冲突而失败，则可能需要禁用 auto.share 属性。

• 存在共享的池之前已导出－如果以只读方式导入池，则该池的属性和文件都无法修改，因此创建新共享会失败。如果在导出池之前存在共享，则可以使用现有共享特征（如果可能）。

下表列出了已知共享状态以及解决它们的方式（如果需要）。

# zfs share FS%share