基于WSL2的Docker挂载物理文件夹至SQL Server容器启动失败求助

问题场景 #

在Windows Server 2022数据中心+WSL2版Docker Desktop环境下，创建SQL Server容器后立即退出（状态码1），日志显示权限拒绝相关错误。此前在Windows Server 2019+Hyper-V Docker环境中相同配置可正常运行，已为docker-users组授予挂载目录D:\Docker\SQL\2022\SQLTest完全控制权限但未生效。

容器启动日志 #

2023-01-02 17:31:56 /opt/mssql/bin/permissions_check.sh: line 4: [: : integer expression expected
2023-01-02 17:31:56 /opt/mssql/bin/permissions_check.sh: line 59: [: : integer expression expected
2023-01-02 17:31:56 SQL Server 2022 will run as non-root by default.
2023-01-02 17:31:56 This container is running as user mssql.
2023-01-02 17:31:56 To learn more visit https://go.microsoft.com/fwlink/?linkid=2099216.
2023-01-02 17:32:59 ** ERROR: [AppLoader] Failed to load LSA: 0xc0070102
2023-01-02 17:32:59 AppLoader: Exiting with status=0xc0070102
2023-01-02 17:32:59 This program has encountered a fatal error and cannot continue running at Mon Jan  2 10:32:59 2023
2023-01-02 17:32:59 The following diagnostic information is available:
2023-01-02 17:32:59 
2023-01-02 17:32:59          Reason: 0x00000006
2023-01-02 17:32:59         Message: Termination of \SystemRoot\system32\AppLoader.exe was due to fatal error 0xC0000001
2023-01-02 17:32:59         Address: 0x3fff9c66a3ec
2023-01-02 17:32:59     Stack Trace:
2023-01-02 17:32:59                  file://package5/windows/system32/sqlpal.dll+0x0000000000209902
2023-01-02 17:32:59                  file://package5/windows/system32/sqlpal.dll+0x0000000000207E7A
2023-01-02 17:32:59                  file://package5/windows/system32/sqlpal.dll+0x000000000026A554
2023-01-02 17:32:59                  file://package5/windows/system32/sqlpal.dll+0x000000000026A3EC
2023-01-02 17:32:59                  file://package5/windows/system32/sqlpal.dll+0x0000000000268D28
2023-01-02 17:32:59                  file://package5/windows/system32/sqlpal.dll+0x0000000000201F5E
2023-01-02 17:32:59                  file://package5/windows/system32/sqlpal.dll+0x000000000039F6D8
2023-01-02 17:32:59                  file:///windows/system32/AppLoader.exe+0x0000000000002ED7
2023-01-02 17:32:59                  file:///windows/system32/AppLoader.exe+0x000000000000301D
2023-01-02 17:32:59                  file:///windows/system32/AppLoader.exe+0x000000000000303D
2023-01-02 17:32:59                  file:///windows/system32/AppLoader.exe+0x000000000000A378
2023-01-02 17:32:59                  file:///Windows/SYSTEM32/KERNEL32.DLL+0x0000000000017DF4
2023-01-02 17:32:59                  file:///windows/system32/ntdll.dll+0x000000000005B7C1
2023-01-02 17:32:59         Process: 9 - sqlservr
2023-01-02 17:32:59          Thread: 84 (application thread 0x128)
2023-01-02 17:32:59     Instance Id: 380bb4ed-2d23-4baa-8762-3d22ee32eb0d
2023-01-02 17:32:59        Crash Id: 10065506-dab0-4d16-849d-e327ed0a3da5
2023-01-02 17:32:59     Build stamp: d81e9b6de06534e649bd57dd609aa3050f5e380f361b7f8a80a80eeb71e7422c
2023-01-02 17:32:59    Distribution: Ubuntu 20.04.5 LTS
2023-01-02 17:32:59      Processors: 20
2023-01-02 17:32:59    Total Memory: 29440778240 bytes
2023-01-02 17:32:59       Timestamp: Mon Jan  2 10:32:59 2023
2023-01-02 17:32:59 Capturing a dump of 9
2023-01-02 17:33:07 Executing: /opt/mssql/bin/handle-crash.sh with parameters
2023-01-02 17:33:07      handle-crash.sh
2023-01-02 17:33:07      /opt/mssql/bin/sqlservr
2023-01-02 17:33:07      9
2023-01-02 17:33:07      /opt/mssql/bin
2023-01-02 17:33:07      /var/opt/mssql/log/
2023-01-02 17:33:07      
2023-01-02 17:33:07      380bb4ed-2d23-4baa-8762-3d22ee32eb0d
2023-01-02 17:33:07      10065506-dab0-4d16-849d-e327ed0a3da5
2023-01-02 17:33:07      
2023-01-02 17:33:07      /var/opt/mssql/log/core.sqlservr.1_2_2023_10_32_59.9
2023-01-02 17:33:07 Successfully captured dump: /var/opt/mssql/log/core.sqlservr.1_2_2023_10_32_59.9
2023-01-02 17:33:07 
2023-01-02 17:33:08 Ubuntu 20.04.5 LTS
2023-01-02 17:33:08 Capturing core dump and information to /var/opt/mssql/log...
2023-01-02 17:33:08 /bin/cat: /proc/9/maps: Permission denied
2023-01-02 17:33:09 /bin/cat: /proc/9/environ: Permission denied
2023-01-02 17:33:09 /usr/bin/find: '/proc/9/map_files': Permission denied
2023-01-02 17:33:09 /usr/bin/find: '/proc/9/map_files': Permission denied
2023-01-02 17:33:09 /usr/bin/find: '/proc/9/map_files': Permission denied
2023-01-02 17:33:09 /usr/bin/find: '/proc/9/map_files': Permission denied
2023-01-02 17:33:10 dmesg: read kernel buffer failed: Operation not permitted
2023-01-02 17:33:10 /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
2023-01-02 17:33:10 /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
2023-01-02 17:33:10 Mon Jan  2 10:33:10 UTC 2023 Capturing program information
2023-01-02 17:33:10 Dump already generated: /var/opt/mssql/log/core.sqlservr.1_2_2023_10_32_59.9, moving to /var/opt/mssql/log/core.sqlservr.9.temp/core.sqlservr.9.gdmp
2023-01-02 17:33:10 Moving logs to /var/opt/mssql/log/core.sqlservr.9.temp/log/paldumper-debug.log
2023-01-02 17:33:10 Mon Jan  2 10:33:10 UTC 2023 Capturing program binaries
2023-01-02 17:33:12 Mon Jan  2 10:33:12 UTC 2023 Not compressing the dump files, moving instead to: /var/opt/mssql/log/core.sqlservr.01_02_2023_10_33_08.9.d

容器创建命令 #

docker run --name SQLServer2022Test --restart always -v D:\Docker\SQL\2022\SQLTest:/var/opt/mssql -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=Aa@123456" -e "MSSQL_PID=Developer" -p 3341:1433 -d 9e28798be691

解决方案 #

方案1：调整WSL2挂载目录权限映射 #

WSL2中Windows目录挂载默认权限是777，但SQL Server容器运行的mssql用户（UID 10001）可能无法正确获取所有权。执行以下步骤：

• 打开WSL2终端（如Ubuntu），找到Windows挂载目录：/mnt/d/Docker/SQL/2022/SQLTest
• 修改目录所有权为UID 10001：

  sudo chown 10001:10001 /mnt/d/Docker/SQL/2022/SQLTest -R
  

• 重新启动容器：docker restart SQLServer2022Test

方案2：禁用SQL Server容器非root运行模式 #

在容器创建命令中添加环境变量MSSQL_USER_ID=0，强制容器以root用户运行，绕过权限检查：

docker run --name SQLServer2022Test --restart always -v D:\Docker\SQL\2022\SQLTest:/var/opt/mssql -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=Aa@123456" -e "MSSQL_PID=Developer" -e "MSSQL_USER_ID=0" -p 3341:1433 -d 9e28798be691

注意：此方式会降低容器安全性，仅用于测试环境或临时解决。

方案3：使用WSL2内部目录作为挂载点 #

放弃Windows目录挂载，改用WSL2内部的目录存储SQL Server数据，避免权限映射问题：

• 在WSL2终端创建目录：

  mkdir -p ~/docker/sql/2022/sqltest
  sudo chown 10001:10001 ~/docker/sql/2022/sqltest -R
  

• 修改容器创建命令的挂载路径为WSL2目录：

  docker run --name SQLServer2022Test --restart always -v ~/docker/sql/2022/sqltest:/var/opt/mssql -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=Aa@123456" -e "MSSQL_PID=Developer" -p 3341:1433 -d 9e28798be691
  

方案4：调整WSL2全局权限配置 #

在WSL2的/etc/wsl.conf文件中添加以下配置，修改Windows挂载目录的默认UID/GID映射：

[automount]
enabled = true
options = "metadata,umask=0022,fmask=0022"
mountFsTab = false
[user]
default = root

保存后关闭所有WSL2终端，执行wsl --shutdown重启WSL2，再重新创建容器。

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