Docker容器中SQL Server 2022启动失败：文件/目录未找到

此前可正常启动的SQL Server 2022容器，在主机更新重启后无法启动，错误提示文件或目录未找到，但未明确具体缺失内容。

错误日志 #

Attaching to db-1
db-1  | SQL Server 2022 will run as non-root by default.
db-1  | This container is running as user mssql.
db-1  | Your master database file is owned by mssql.
db-1  | To learn more visit https://go.microsoft.com/fwlink/?linkid=2099216.
db-1  | This program has encountered a fatal error and cannot continue running at Mon Jan 15 16:34:36 2024
db-1  | The following diagnostic information is available:
db-1  | 
db-1  |          Reason: 0x00000001
db-1  |          Signal: SIGABRT - Aborted (6)
db-1  |           Stack:
db-1  |                  IP               Function
db-1  |                  ---------------- --------------------------------------
db-1  |                  000059c04b40ace1 std::__1::bad_function_call::~bad_function_call()+0x96661
db-1  |                  000059c04b40a6a6 std::__1::bad_function_call::~bad_function_call()+0x96026
db-1  |                  000059c04b409c2f std::__1::bad_function_call::~bad_function_call()+0x955af
db-1  |                  000070fbc4529520 __sigaction+0x50
db-1  |                  000070fbc457d9fc pthread_kill+0x12c
db-1  |                  000070fbc4529476 raise+0x16
db-1  |                  000070fbc450f7f3 abort+0xd3
db-1  |                  000059c04b3dbd96 std::__1::bad_function_call::~bad_function_call()+0x67716
db-1  |                  000059c04b4185b4 std::__1::bad_function_call::~bad_function_call()+0xa3f34
db-1  |                  000059c04b446318 std::__1::bad_function_call::~bad_function_call()+0xd1c98
db-1  |                  000059c04b4460fa std::__1::bad_function_call::~bad_function_call()+0xd1a7a
db-1  |                  000059c04b3e220a std::__1::bad_function_call::~bad_function_call()+0x6db8a
db-1  |                  000059c04b3e1e80 std::__1::bad_function_call::~bad_function_call()+0x6d800
db-1  |         Process: 10 - sqlservr
db-1  |          Thread: 157 (application thread 0x264)
db-1  |     Instance Id: c9380e05-c944-4cf5-9342-105397856038
db-1  |        Crash Id: 4b39a473-e76a-47b4-8a49-bb6fd55f2849
db-1  |     Build stamp: a9299dd605c652a3cea4246273441bcfaf48afb4b482ab9dc43771eecaf6600b
db-1  |    Distribution: Ubuntu 22.04.3 LTS
db-1  |      Processors: 32
db-1  |    Total Memory: 67119079424 bytes
db-1  |       Timestamp: Mon Jan 15 16:34:36 2024
db-1  |      Last errno: 2
db-1  | Last errno text: No such file or directory
db-1  | Capturing a dump of 10
db-1  | Executing: /opt/mssql/bin/handle-crash.sh with parameters
db-1  |      handle-crash.sh
db-1  |      /opt/mssql/bin/sqlservr
db-1  |      10
db-1  |      /opt/mssql/bin
db-1  |      /var/opt/mssql/log/
db-1  |      
db-1  |      c9380e05-c944-4cf5-9342-105397856038
db-1  |      4b39a473-e76a-47b4-8a49-bb6fd55f2849
db-1  |      
db-1  |      /var/opt/mssql/log/core.sqlservr.1_15_2024_16_34_36.10
db-1  | Successfully captured dump: /var/opt/mssql/log/core.sqlservr.1_15_2024_16_34_36.10
db-1  | 
db-1  | Ubuntu 22.04.3 LTS
db-1  | Capturing core dump and information to /var/opt/mssql/log...

docker-compose配置文件 #

version: '3'
services:
  db:
    image: 'mcr.microsoft.com/mssql/server:2022-latest'
    environment:
      - ACCEPT_EULA=Y
      - MSSQL_SA_PASSWORD=password1!
    ports:
      - 1433:1433
    volumes:
      - ./data:/var/opt/mssql/data
      - ./log:/var/opt/mssql/log
    expose:
      - 1433

本地目录权限信息 #

本地./data目录的用户组权限为10001:0

解决方案 #

• 修正挂载目录权限：SQL Server容器以mssql用户（UID 10001）运行，需确保./data和./log目录都具备读写权限。执行以下命令：

  sudo chown -R 10001:0 ./data ./log
  sudo chmod -R 755 ./data ./log
  

  完成后重启容器：docker-compose down && docker-compose up -d

• 验证目录文件完整性：主机更新重启可能导致数据库文件损坏或丢失。检查./data下是否存在master.mdf、mastlog.ldf等核心文件。若文件缺失：

  1. 备份现有目录：mv ./data ./data_backup && mv ./log ./log_backup
  2. 重新启动容器初始化新的数据库实例：docker-compose up -d

  注意：此操作会丢失原有数据，仅在无备份时采用。

• 强制容器运行用户：在docker-compose.yml的services.db节点下添加用户配置，避免权限映射问题：

  user: "10001:0"
  

  修改后重启容器。

• 指定固定镜像版本：latest标签可能在主机更新后拉取了不兼容的新版本。替换为具体稳定版本，例如：

  image: 'mcr.microsoft.com/mssql/server:2022-CU12-ubuntu-22.04'
  

  重新拉取镜像并启动容器：docker-compose pull && docker-compose up -d

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