Paket corrupt packages when restore on linux

Description

I am building a project using docker with debian-9 target. When docker command is executed RUN dotnet restore "src/my_project.fsproj" --disable-parallel I get output:

  Paket version 5.194.4
  Paket version 5.194.4
  Starting full restore process.
  Downloading FSharp.Data 3.0 (Build)
  Downloading FAKE 4.64.13 (Build)
  Downloading ilmerge 2.14.1208 (Build)
  Downloading Microsoft.VisualStudio.Azure.Containers.Tools.Targets 1.0.2105168 (Build)
  Downloading xunit.runner.console 2.4.1 (Build)
  Starting full restore process.
  Downloading FAKE 4.64.13 (Build)
  Downloading FSharp.Data 3.0 (Build)
  Downloading ilmerge 2.14.1208 (Build)
  Downloading Microsoft.VisualStudio.Azure.Containers.Tools.Targets 1.0.2105168 (Build)
  Downloading xunit.runner.console 2.4.1 (Build)
  Download of ilmerge 2.14.1208 (Build) done in 2 seconds. (1121 kbit/s, 0 MB)
  Download of Microsoft.VisualStudio.Azure.Containers.Tools.Targets 1.0.2105168 (Build) done in 2 seconds. (1927 kbit/s, 0 MB)
  Something went wrong while downloading ilmerge 2.14.1208
  Message: /root/.nuget/packages/ilmerge/2.14.1208/ilmerge.nuspec does not exist
    ==> Trying again

other error messages:

Something went wrong while downloading xunit.runner.console 2.4.1
Message: A local file header is corrupt.

Something went wrong while downloading xunit.runner.console 2.4.1
Message: Could not find a part of the path "/src/packages/build/xunit.runner.console/xunit.runner.console.2.4.1.nupkg".

Observations:

• I have provided --disable-parallel flag to dotnet restore command
• It seems 2 instances of paket were run and FSharp.Data 3.0 and others were downloaded and unpacked in parallel.
• Target system is linux, where file lock semantic is different from windows.
• There is variety of file corruption messages which is consistent with 2 processes modifying the same
  files/directories.
• Project in question is referencing multi-targeted projects and a lot of nuget dependencies.

Repro steps

Not sure how to reproduce, it is large project and parallel processes are timing sensitive. I hope it should be obvious from paket's locking analysis.

Expected behavior

Paket should not corrupt files when invoked by dotnet restore

Known workarounds

Run mono .paket/paket.exe restore instead of dotnet restore

Start with the dotnet restore entry point and compare it with the working mono .paket/paket.exe restore workaround, focusing on the locking analysis mentioned in the report. A fix is complete when dotnet restore no longer runs competing Paket instances or corrupts package files on Linux.