Azure上Docker部署WordPress挂载Azure File Share后媒体无法访问咨询

解决方案 #

1. 修正Azure File Share挂载权限 #

这是此类问题最常见的诱因：Azure App Service默认以root身份挂载SMB协议的Azure File Share，挂载后的文件/目录所有者为root（uid=0），而WordPress运行时使用的www-data用户uid通常为33，无对应读取权限，就会导致静态资源访问返回502错误。
操作方法：

• 进入App Service「配置」-「路径映射」页面，找到你配置的File Share挂载项
• 在「装载选项」输入框填入：uid=33,gid=33,file_mode=0644,dir_mode=0755
• 保存配置，等待App Service重启生效
  同时确认应用设置中WEBSITES_ENABLE_APP_SERVICE_STORAGE参数值为true。

2. 验证自定义镜像的Web服务配置 #

如果是自行构建的Docker镜像，需要确认Web服务器（Apache/Nginx）对挂载的媒体目录没有访问限制：

• 若使用Apache，确保/var/www/html/wp-content/目录的配置中开启了AllowOverride All，且没有禁止静态资源访问的规则
• 若使用Nginx，确保配置文件中存在匹配/wp-content/uploads/或自定义媒体路径的静态资源解析规则，没有额外的访问控制拦截

3. 校验WordPress路径配置 #

确认你在WORDPRESS_CONFIG_EXTRA中添加的路径参数和实际挂载路径一致：
如果你将File Share挂载到/var/www/html/wp-content/uploads，对应的配置应为：

define( 'UPLOADS', 'wp-content/uploads' );

同时确认WordPress后台「设置」-「常规」中的「WordPress地址（URL）」和「站点地址（URL）」和你实际访问的App Service域名完全一致，避免资源路径生成错误。

注意：直接访问Azure File Share的原生URL报错是正常现象，Azure Files默认不支持匿名公开访问，所有媒体资源的访问都要走App Service的Web服务链路，不需要额外调整存储账号的公开访问配置。

简化部署方案 #

如果不想自行维护Docker镜像和挂载配置，可以选择以下两种更稳定的方案：

1. 使用Azure官方提供的「WordPress on App Service」预配置模板，部署时自动完成MySQL、Azure Files挂载、权限配置等所有环节，开箱即用，无需手动调整挂载参数
2. 使用Azure Blob Storage存储媒体文件：安装WordPress对应Azure存储插件，配置存储账号的访问密钥后，所有媒体文件会直接上传到Blob存储，自动使用Blob的公开访问URL提供服务，无需配置本地路径挂载，还可对接Azure CDN提升全球访问速度。

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