WSL环境下docker-compose部署WordPress与VSCode文件权限冲突问题

方案1：用户组权限适配（无需修改Docker配置） #

核心逻辑是让WSL当前用户和WordPress运行的www-data用户同属一个共享组，同时给组分配读写权限：

1. 将当前WSL用户加入www-data用户组

sudo usermod -aG www-data $USER

执行后需关闭WSL终端重新打开，或执行su - $USER使组配置生效。
2. 递归设置项目目录的属主、属组

sudo chown -R $USER:www-data /path/to/your/Projects

将路径替换为你实际的项目文件夹路径。
3. 设置目录SGID继承位与读写权限

• 给所有目录设置SGID位，保证后续新建的文件/目录自动继承父目录的www-data属组，同时授予属主、属组读写执行权限：

find /path/to/your/Projects -type d -exec chmod 2775 {} \;

• 给所有文件授予属主、属组读写权限：

find /path/to/your/Projects -type f -exec chmod 664 {} \;

4. 配置WordPress默认权限规则
   在WordPress根目录的wp-config.php文件中加入以下两行配置，保证WordPress新建的文件自动开放组读写权限：

define('FS_CHMOD_DIR', 0775);
define('FS_CHMOD_FILE', 0664);

方案2：Docker运行用户ID对齐（彻底解决权限不一致问题） #

核心逻辑是将容器内运行WordPress的www-data用户的UID/GID修改为和你WSL当前用户的UID/GID完全一致，从根源消除权限差异：

1. 先查询你WSL当前用户的UID和GID

id $USER

默认Ubuntu 20.04的第一个普通用户UID为1000、GID为1000，以下步骤以该值为例，可根据实际查询结果替换。
2. 为WordPress服务自定义镜像
在你的docker-compose.yml同级目录新建Dockerfile.wordpress文件，内容如下：

FROM wordpress:latest
# 将容器内www-data的UID/GID替换为你的WSL用户ID
RUN usermod -u 1000 www-data && groupmod -g 1000 www-data

3. 修改docker-compose.yml配置
   将原有WordPress服务的image字段替换为本地构建配置：

services:
  wordpress:
    build:
      context: .
      dockerfile: Dockerfile.wordpress
    # 其余原有配置保持不变

4. 重建WordPress容器

docker-compose up -d --build wordpress

WSL配置优化 #

你当前wsl.conf中的umask=22会默认取消组的写权限，建议修改为umask=002，保证新建文件默认开放组写权限：

[automount]
enabled = true
root = /windir/
options = "metadata,umask=002,fmask=113"
mountFsTab = false

修改完成后执行wsl --shutdown关闭WSL实例，重新打开后配置生效。

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