排查 NFS Azure 文件共享问题
注意
本文中引用的 CentOS 是 Linux 分发版,将达到生命周期结束(EOL)。 请相应地考虑使用和规划。 有关详细信息,请参阅 CentOS 生命周期指南。
本文列出了与 NFS Azure 文件共享相关的常见问题,并介绍了可能的原因和解决方法。
重要
本文内容仅适用于 NFS 共享。 若要排查 Linux 中的 SMB 问题,请参阅排查 Linux (SMB) 中的 Azure 文件存储问题。 Windows 不支持 NFS Azure 文件共享。
适用于
文件共享类型 | SMB | NFS |
---|---|---|
标准文件共享 (GPv2)、LRS/ZRS | ||
标准文件共享 (GPv2)、GRS/GZRS | ||
高级文件共享 (FileStorage)、LRS/ZRS |
chgrp“filename”失败:参数 (22) 无效
原因 1:未禁用 idmapping
由于 Azure 文件存储不允许字母数字 UID/GID,必须禁用 idmapping。
原因 2:已禁用 idmapping,但遇到错误的文件/目录名称后重新启用
即使正确禁用了 idmapping,在某些情况下它也会自动重新启用。 例如,Azure 文件在遇到错误的文件名时会返回错误。 看到此错误代码后,NFS 4.1 Linux 客户端决定重新启用 idmapping,并使用字母数字 UID/GID 发送将来的请求。 有关 Azure 文件存储中不受支持的字符的列表,请参阅此文章。 冒号是不受支持的字符之一。
解决方法
请确保你已禁用 idmapping,并且没有任何项正在重新启用它。 接下来,请执行下列步骤:
卸载共享。
禁用 IDmapping,并使用以下功能:
sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
将共享装载回。
如果运行 rsync,请使用
—numeric-ids
目录中没有错误的目录或文件名的参数运行 rsync。
无法创建 NFS 共享
原因:不支持的存储帐户设置
NFS 只能在具有以下配置的存储帐户上使用:
- 层级 - 高级
- 帐户类型 - FileStorage
- 区域 - 受支持区域的列表
解决方案
按照如何创建 NFS 共享中的说明进行操作。
无法连接或装载 NFS Azure 文件共享
原因 1:请求来自不受信任的网络/不受信任的 IP 中的客户端
不同于 SMB,NFS 没有基于用户的身份验证。 用于共享的身份验证基于网络安全规则配置。 为了确保客户端仅与你的 NFS 共享建立安全连接,必须使用服务终结点或专用终结点。 若要从本地访问共享以及专用终结点,必须设置 VPN 或 ExpressRoute 连接。 系统将忽略添加到存储帐户防火墙允许列表中的 IP。 必须使用以下方法之一来设置对 NFS 共享的访问权限:
原因 2:启用了所需的安全传输
NFS Azure 文件共享目前不支持双重加密。 Azure 使用 MACSec 为 Azure 数据中心之间传输的所有数据提供加密层。 只能从受信任的虚拟网络和 VPN 隧道访问 NFS 共享。 NFS 共享上没有额外的传输层加密可用。
解决方案
在存储帐户的配置边栏选项卡中禁用 所需的 安全传输。
原因 3:未安装 nfs-utils、nfs-client 或 nfs-common 包
在运行 mount
命令之前,请安装 nfs-utils、nfs-client 或 nfs-common 包。
若要检查 NFS 包是否已安装,请运行:
解决方案
如果未安装此包,请使用特定于你的发行版的命令来安装包。
本节中的相同命令适用于 CentOS 和 Oracle Linux。
OS 版本 7.X
sudo yum install nfs-utils
OS 版本 8.X 或 9.X
sudo dnf install nfs-utils
原因 4:防火墙阻止端口 2049
NFS 协议通过端口 2049 与其服务器通信。 确保此端口对存储帐户(NFS 服务器)开放。
解决方案
运行以下命令,验证是否已在客户端上开启端口2049。 如果端口未开启,请开启它。
sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049
原因 5:存储帐户已删除
如果由于错误而无法装载文件共享 :连接超时,则包含文件共享的存储帐户可能会意外删除。
解决方案
恢复存储帐户。 然后,删除并重新创建专用终结点,使其与新的存储帐户资源 ID 相关联。
ls 在某些内核上挂起以进行大型目录枚举
原因:Linux 内核 v5.11 中引入了 bug,已在 v5.12.5 中修复
某些内核版本存在 bug,该 bug 会使目录列表生成无限的 READDIR 序列。 小型目录(其中所有条目均可在一次调用中传递)不会产生此问题。 Linux 内核 v5.11 中引入了一个 bug,并且已在 v5.12.5 中修复。 这两个版本之间的版本均存在 bug。 RHEL 8.4 具有此内核版本。
解决方法:降级或升级内核
将内核降级或升级到受影响的内核之外的任何版本都应该能解决该问题。
系统命令失败,出现“找不到文件”错误
原因
由于 NFS 服务生成的 64 位 inode 数字的格式设置,依赖于 inode 数字的 Linux 32 位应用程序可能无法按预期方式运行Azure 文件存储。
解决方案
若要解决此问题,请使用以下一种方法:
使用
nfs.enable_ino64=0
内核启动选项将 64 位 inode 数字压缩到 32 位。通过添加到
options nfs enable_ino64=0
/etc/modprobe.d/nfs.conf 文件并重新启动 VM 来设置模块参数。
还可以在 grub.conf 文件中保留此内核启动选项。 有关详细信息,请参阅 Linux 分发版的文档。
无法更改文件和目录的所有权
原因
客户端 OS 而不是 Azure 文件存储 服务强制实施对 NFS 文件共享的权限。 如果在 NFS 文件共享上启用了根 Squash 设置,则客户端系统上的根用户被视为匿名(非特权)用户,以便进行访问控制。 这意味着,即使以根身份登录到客户端系统上,也不能使用 chown
命令更改你不拥有的文件和目录的所有权。
解决方案
在Azure 门户中,导航到文件共享并选择“属性”。 将根壁球设置更改为“无根壁球”。 有关详细信息,请参阅配置Azure 文件存储的根壁球。
启用 Root Squash 后,客户端系统上的根用户与服务器系统上的根用户具有相同的权限。 现在,无论当前所有者如何,都可以用于 chown
更改共享中任何文件或目录的所有权。 进行更改后,可以根据需要重新启用 根壁球 。
需要帮助?
如果仍需帮助,请联系支持人员,以快速解决问题。
另请参阅
- 对 Azure 文件进行故障排除
- 排查 Azure 文件存储性能问题
- 排查 Azure 文件存储连接性问题 (SMB)
- 排查 Azure 文件存储身份验证和授权 (SMB) 问题
- 排查 Linux 上的 Azure 文件存储一般 SMB 问题
联系我们寻求帮助
如果你有任何疑问或需要帮助,请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。