AKS挂载Azure文件共享报错mount error(13): Permission denied

已排除区域不一致、密钥值肉眼匹配的前提下，按以下优先级定位根因：跨订阅、跨资源组本身不会导致挂载失败，核心问题集中在网络、凭据隐性错误、驱动兼容性三类：

1. 存储账户网络防火墙拦截（最高概率，和你提到的跨VNET场景直接相关） #

Azure Files默认CIFS挂载走公网端点fastorage.file.core.windows.net，如果存储账户防火墙配置为「仅允许选定虚拟网络/IP访问」，跨VNET、跨订阅的AKS节点IP不在允许列表时，会直接返回权限拒绝报错，和密钥正确性完全无关。

• 验证方法：临时将存储账户防火墙调整为允许所有网络访问，重新触发Pod调度挂载，若挂载成功即可确认是该问题。
• 修复方案：
  • 公网挂载场景：将AKS节点池的出站公网IP、AKS集群出口公网IP段全部加入存储账户防火墙的允许IP列表。
  • 私网挂载场景：为存储账户创建Azure Files服务的私有终结点，打通AKS所在VNET和存储账户所在VNET的对等互联，确保AKS节点可解析存储账户文件服务的私网IP，同时在存储账户防火墙中放通对等VNET的访问权限。

2. 存储凭据的隐性配置错误 #

肉眼核对密钥匹配不代表Secret中实际存储的值正确，重点排查两个易漏点：

• Windows端执行kubectl create secret命令时，PowerShell/CMD的引号转义规则可能导致密钥值被截断、额外加入转义字符。执行以下命令解码Secret中实际存储的密钥，和存储账户后台的访问密钥逐字符比对：

  kubectl get secret fa-fileshare-secret -o jsonpath='{.data.azurestorageaccountkey}' | base64 -d
  

• 若存储账户近期轮换过访问密钥，Secret中存储的旧密钥会直接失效，建议重新复制存储账户Key1/Key2的完整值，删除旧Secret后重新创建再重试。
• 注意：旧版树内Azure Files驱动不支持SAS令牌作为挂载凭据，必须使用存储账户完整访问密钥。

3. 手动挂载隔离K8s层问题 #

找一台和AKS节点同网络环境的Linux机器，执行和kubelet一致的CIFS挂载命令手动测试，快速隔离问题层级：

mkdir /testmount
mount -t cifs //fastorage.file.core.windows.net/containershare /testmount -o vers=3.0,username=fastorage,password=替换为你的存储账户实际密钥,dir_mode=0777,file_mode=0777

• 若手动挂载同样返回13权限错误：问题和K8s配置无关，回到网络、密钥有效性方向排查。
• 若手动挂载成功：问题出在K8s Azure Files驱动层，参考下一节排查。

4. 驱动兼容性与配置问题 #

你当前使用的是已进入弃用流程的树内（in-tree）Azure Files卷插件，在新版AKS集群、安全加固节点上存在已知兼容性问题：

• 若存储账户为启用了分层命名空间的ADLS Gen2账户，树内驱动不支持挂载该类文件共享，需迁移到Azure Files CSI驱动，通过PVC方式挂载。
• 若存储账户开启了Azure AD/AD DS域身份验证用于SMB访问，默认会禁用存储密钥的挂载权限，树内驱动不支持域认证挂载，要么临时关闭存储账户的基于身份的访问功能测试，要么迁移到CSI驱动配置域认证参数。
• 若存储账户强制要求SMB 3.0及以上版本连接，部分旧版节点的CIFS客户端默认使用SMB 2.x版本会被拒绝，迁移到CSI驱动后会自动适配最新的SMB协议参数。

内容的提问来源于stack exchange，提问作者vel