title: MSSQL container fails to start when mapping volumes after upgrading to WSL2
body: <p>After I changed Docker Desktop to use WSL2, I am unable to start an mssql image using Docker-compose.</p>
  <p>If I don't map the volumes the container starts up.</p>
  <p><strong>Docker-compose</strong></p>
  <pre><code>services:
    db:
      image: &quot;mcr.microsoft.com/mssql/server:2019-latest&quot;
      container_name: mssql
      environment:
          SA_PASSWORD: &quot;***********&quot;
          ACCEPT_EULA: &quot;Y&quot;
      ports:
      - 1433:1433
      volumes:
      - ~/docker/sql/mssql/:/var/opt/mssql/
      - ~/docker/sql/sqlserver/:/var/opt/sqlserver/
      healthcheck:
        test: /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P &quot;$$SA_PASSWORD&quot; -Q &quot;SELECT 1&quot; || exit 1
        interval: 30s
        timeout: 30s
        retries: 3
  </code></pre>
  <p><strong>Error</strong></p>
  <pre><code>** ERROR: [AppLoader] Failed to load LSA: 0xc0070102
  AppLoader: Exiting with status=0xc0070102
  This program has encountered a fatal error and cannot continue running at Tue Dec 15 13:49:34 2020
  The following diagnostic information is available:
  
  Reason: 0x00000006
  Message: Termination of \SystemRoot\system32\AppLoader.exe was due to fatal error 0xC0000001
  Address: 0x3fffb0c551f1
  Stack Trace:
  file://package4/windows/system32/sqlpal.dll+0x000000000030E7D9
  file://package4/windows/system32/sqlpal.dll+0x000000000030C769
  file://package4/windows/system32/sqlpal.dll+0x0000000000255F1D
  file://package4/windows/system32/sqlpal.dll+0x00000000002551F1
  file://package4/windows/system32/sqlpal.dll+0x0000000000254A72
  file://package4/windows/system32/sqlpal.dll+0x0000000000254B4B
  file://package4/windows/system32/sqlpal.dll+0x0000000000202FE2
  file://package4/windows/system32/sqlpal.dll+0x0000000000347898
  file:///windows/system32/AppLoader.exe+0x0000000000003C90
  file:///Windows/SYSTEM32/KERNEL32.DLL+0x0000000000014414
  file:///windows/system32/ntdll.dll+0x0000000000075541
  &lt;unknown&gt;+0x00000000FC3FE000
  Process: 10 - sqlservr
  Thread: 39 (application thread 0x68)
  Instance Id: 7cfc9545-c829-4a7e-a461-83b481fe05e3
  Crash Id: b747c621-d4e2-46ed-9122-f14a8d54386a
  Build stamp: fd4eb1565f159d8f4b2d49c48e96d5797508c8bc5f222def3def149a28435962
  Distribution: Ubuntu 18.04.5 LTS
  Processors: 8
  Total Memory: 13339308032 bytes
  Timestamp: Tue Dec 15 13:49:34 2020
  
  Ubuntu 18.04.5 LTS
  Capturing core dump and information to /var/opt/mssql/log...
  /bin/cat: /proc/10/maps: Permission denied
  /bin/cat: /proc/10/environ: Permission denied
  /usr/bin/find: '/proc/10/map_files': Permission denied
  /usr/bin/find: '/proc/10/map_files': Permission denied
  /usr/bin/find: '/proc/10/map_files': Permission denied
  /usr/bin/find: '/proc/10/map_files': Permission denied
  dmesg: read kernel buffer failed: Operation not permitted
  /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
  /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
  Tue Dec 15 13:49:36 UTC 2020 Capturing program information
  Tue Dec 15 13:49:36 UTC 2020 Attempting to capture a dump with paldumper for pid 10
  WARNING: Capture attempt failure detected
  Attempting to capture a filtered dump with paldumper for pid 10
  WARNING: Attempt to capture dump failed. Reference /var/opt/mssql/log/core.sqlservr.10.temp/log/paldumper-debug.log for details
  
  Tue Dec 15 13:49:36 UTC 2020 Attempting to capture a dump with gdb
  Tue Dec 15 13:49:36 UTC 2020 Captured a dump with gdb
  Tue Dec 15 13:49:36 UTC 2020 Capturing program binaries
  Tue Dec 15 13:49:36 UTC 2020 Compressing the dump files
  </code></pre>
  <p><strong>wsl --list --verbose</strong></p>
  <pre><code>  NAME                   STATE           VERSION
  * Ubuntu-20.04           Running         2
    docker-desktop         Running         2
    docker-desktop-data    Running         2
  </code></pre>