Dotnet-docker: Error when using dotnet/core/aspnet:3.1 - Folder [/usr/share/dotnet/host/fxr] does not contain any version-numbered child folders

[sandeshkg]

Steps to reproduce the issue

1. Downloaded the dotnet/core/aspnet:3.1 image on Redhat Linux Server using - docker image pull mcr.microsoft.com/dotnet/core/aspnet:3.1
2. docker run -it /bin/bash
3. dotnet --info

Expected behavior

Should have displayed information reated to dotnet

Actual behavior

root@d9a4936ea0bf:/# dotnet --info
A fatal error occurred, the folder [/usr/share/dotnet/host/fxr] does not contain any version-numbered child folders

Additional information (e.g. issue happens only occasionally)

Trying to deploy a aspnet core 3.1 docker app and the container does not launch. Always failed with above mentioned error.
Pulled the base image and did a docker run -it /bin/bash. Once in the container, if i run 'ls' command, i get below error-->
ls: cannot open directory '.': Permission denied.
Then tried dotnet --info and received the below error -
root@d9a4936ea0bf:/# dotnet --info
A fatal error occurred, the folder [/usr/share/dotnet/host/fxr] does not contain any version-numbered child folders

Output of docker version

Client:
 Version:         1.13.1
 API version:     1.26
 Package version: docker-1.13.1-104.git4ef4b30.el7.x86_64
 Go version:      go1.10.3
 Git commit:      4ef4b30/1.13.1
 Built:           Tue Sep 24 18:53:48 2019
 OS/Arch:         linux/amd64

Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: docker-1.13.1-104.git4ef4b30.el7.x86_64
 Go version:      go1.10.3
 Git commit:      4ef4b30/1.13.1
 Built:           Tue Sep 24 18:53:48 2019
 OS/Arch:         linux/amd64
 Experimental:    false

Output of docker info

Containers: 10
 Running: 1
 Paused: 0
 Stopped: 9
Images: 4
Server Version: 1.13.1
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Authorization: rhel-push-plugin
Swarm: active
 NodeID: ovkrhpwls9rm6rclwcvj7eajp
 Is Manager: true
 ClusterID: 7rvil11lvj4q8r8v7jnisbjui
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: 10.x.x.x
 Manager Addresses:
  10.x.x.x:2377
Runtimes: docker-runc runc
Default Runtime: docker-runc
Init Binary: /usr/libexec/docker/docker-init-current
containerd version:  (expected: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1)
runc version: 9c3c5f853ebf0ffac0d087e94daef462133b69c7 (expected: 9df8b306d01f59d3a8029be411de015b7304dd8f)
init version: fec3683b971d9c3ef73f284f176672c44b448662 (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
 seccomp
  WARNING: You're not using the default seccomp profile
  Profile: /etc/docker/seccomp.json
 selinux
Kernel Version: 3.10.0-862.el7.x86_64
Operating System: Red Hat Enterprise Linux
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 3
CPUs: 4
Total Memory: 7.631 GiB
Name: noname.server.lab.com
ID: KDH4:D2CQ:JL3D:ZJEQ:3HNK:C23H:DP7J:NY4I:YGFZ:GBA2:Y6DG:GTSH
Docker Root Dir: /opt/app/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://registry.access.redhat.com/v1/
Experimental: false
Insecure Registries:
 10.x.x.x:5000
 127.0.0.0/8
Live Restore Enabled: false
Registries: registry.access.redhat.com (secure), docker.io (secure), registry.fedoraproject.org (secure), quay.io (secure), registry.centos.org (secure), docker.io (secure)

[MichaelSimons]

I was not able to reproduce this on the RHEL machine I have access to.

Given the following statement, it seems there is something else related that is not related directly to the .NET Core images.

Pulled the base image and did a docker run -it /bin/bash. Once in the container, if i run 'ls' command, i get below error-->
ls: cannot open directory '.': Permission denied.

Can you clarify what you are referring to as the _base image_? Have you tried ls with the debian:buster-slim image?

[sandeshkg]

@MichaelSimons By Base image i was referring to - mcr.microsoft.com/dotnet/core/aspnet:3.1 without any application components. I looked at it further on other Redhat machines and i could get the image working as expected. Problem was this specific server had SELinux enabled causing the error. Thanks for your time. I am able to progress.

[appcoreopc]

I am facing the same issue as well. When i run anything to do with 'dotnet' e.g. dotnet -h, dotnet -version. i got the "A fatal error occurred, the folder [/usr/share/dotnet/host/fxr] does not contain any version-numbered child folders".

-Linux (Red Hat 4.8.5-39) - giving this error
-Not issues with running it on Ubuntu bionic.

Any workaround would be greatly appreciated but i need to target netcore3.0

[kpakur]

The same for me. I try to build to arm32v7 an IoT Edge solution in VSCode on Windows.
Step 4/12 : RUN dotnet restore ---> Running in f27622ae0751 A fatal error occurred, the folder [/usr/share/dotnet/host/fxr] does not contain any version-numbered child folders

Dockerfile.arm32v7
`FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster-arm32v7 AS build-env
WORKDIR /app

COPY *.csproj ./
RUN dotnet restore

COPY . ./
RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/core/runtime:3.1-buster-slim-arm32v7
WORKDIR /app
COPY --from=build-env /app/out ./

RUN useradd -ms /bin/bash moduleuser
USER moduleuser

ENTRYPOINT ["dotnet", "SampleModule.dll"]
`

Command
docker build --rm -f "c:\work\temp\EdgeSolutionNet31\modules\SampleModule\Dockerfile.arm32v7" -t localhost:5000/samplemodule:0.0.1-arm32v7 "c:\work\temp\EdgeSolutionNet31\modules\SampleModule"

[MichaelSimons]

@kpakur - Can you please include the output of docker info and docker version? Is your Docker host arm32v7?

[kpakur]

@MichaelSimons, I have docker installed in Win10 (AMD64) (btw on sdk:2.1 and appropriate docker image all works fine)
`$ docker version
Client: Docker Engine - Community
Version: 19.03.8
API version: 1.40
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:23:10 2020
OS/Arch: windows/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.12)
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:29:16 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version: 0.18.0
GitCommit: fec3683`

`$ docker info
Client:
Debug Mode: false

Server:
Containers: 14
Running: 4
Paused: 0
Stopped: 10
Images: 111
Server Version: 19.03.8
Storage Driver: overlay2
Backing Filesystem:
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 4.19.76-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.943GiB
Name: docker-desktop
ID: GKNV:2WI2:JYFJ:2MOT:EEHC:53Y6:EUPV:L24D:VBDS:WBDM:DMBW:CHXS
Docker Root Dir: /var/lib/docker
Debug Mode: true
File Descriptors: 71
Goroutines: 101
System Time: 2020-04-16T22:32:21.760388534Z
EventsListeners: 4
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine`

[MichaelSimons]

@kpakur - Please see our guidance for building arm image. You can not run .NET within arm32 images on amd64 hosts but it is possible to build an .NET arm32 image on an amd64 host using the this pattern. The subtle difference here is you are using an amd64 SDK image to product the arm32 binaries that get copied to the resulting arm32 image.

[kpakur]

@MichaelSimons thanks I will try this out.
Interesting is that for a different image and sdk2.1 it works fine (same machine, docker, windows, etc), ok I see there is different sdk image there-not the arm one
`FROM mcr.microsoft.com/dotnet/core/sdk:2.1 AS build-env
WORKDIR /app

COPY *.csproj ./
RUN dotnet restore

COPY . ./
RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/core/runtime:2.1-stretch-slim-arm32v7
WORKDIR /app
COPY --from=build-env /app/out ./

RUN useradd -ms /bin/bash moduleuser
USER moduleuser

ENTRYPOINT ["dotnet", "Smaple2Module.dll"]`

[MichaelSimons]

@kpakur - The SDK image in your 2.1 Dockerfile is using a multi-platform tag. When you build this on an amd64 host, you will get a amd64 image. Your 3.1 Dockerfile is using an arm32 sdk tag - mcr.microsoft.com/dotnet/core/sdk:3.1-buster-arm32v7. This is what causes the issue because that is an arm32 image. Running .NET in an arm32 image on a amd64 host is not supported. If you changed the 3.1 SDK tag to be an amd64 tag e.g. mcr.microsoft.com/dotnet/core/sdk:3.1-buster, then it would work.

[kpakur]

@MichaelSimons Thanks for your help. I compiled the IoT Edge Module on Windows 10 and then successfully got it up and running on Raspberry Pi 2.
I also added an issue to the VSCode Extension so the generated Dockerfile file is corrected. https://github.com/microsoft/vscode-azure-iot-edge/issues/543

[devedse]

@kpakur - Please see our guidance for building arm image. You can not run .NET within arm32 images on amd64 hosts but it is possible to build an .NET arm32 image on an amd64 host using the this pattern. The subtle difference here is you are using an amd64 SDK image to product the arm32 binaries that get copied to the resulting arm32 image.

How would you go around implementing this pattern in combination with docker buildx?

[MichaelSimons]

@devedse, using docker buildx will be compatible with this pattern.

[devedse]

@MichaelSimons , so how would you let buildx build images for multiple architectures without having multiple docker files?

I want to build an image for ARM32, ARM64, X86 and X64 in one go. If I use "this pattern" I have to hardcore the image it creates. I can't use the normal buildx functionality to generate it based on the specified architectures.

For example, normally you'd use a command like this:

docker buildx build -f DeveMazeGeneratorCore.Web/Dockerfile --platform linux/arm,linux/arm64,linux/amd64 -t devedse/devemazegeneratorcoreweb .

This however fails since building on arm32 is not supported.

Edit:
I posted a more elaborate version of this question on stackoverflow:
https://stackoverflow.com/questions/65451368/building-arm32-image-with-dotnet-on-x64-platform-with-buildx-throws-error

[MichaelSimons]

@devedse, One option that may work for you is to hard code the SDK to use an AMD64 image as shown below.

# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim-amd64 AS build
WORKDIR /source

# copy csproj and restore as distinct layers
COPY *.csproj .
RUN dotnet restore

# copy and publish app and libraries
COPY . .
# Set UseAppHost=false to avoid creating a rid specific executable.
# Without this, the executable would be linux-amd64 specific.
RUN dotnet publish -c release -o /app /p:UseAppHost=false --no-restore

# final stage/image
FROM mcr.microsoft.com/dotnet/runtime:5.0
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "dotnetapp.dll"]

This will build with docker buildx build --platform linux/arm,linux/arm64,linux/amd64 -t dotnetapp . within a linux amd64 environment. It won't build on other architectures because of the hard-coded amd64 sdk image.

If you want to publish a self-contained app or you want to produce an executable, you could make use of the special TARGETPLATFORM ARG as shown below.

# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim-amd64 AS build
WORKDIR /source

ARG TARGETPLATFORM

COPY . .
RUN if [ "$TARGETPLATFORM" = "linux/amd64" ]; then \
        RID=linux-x64 ; \
    elif [ "$TARGETPLATFORM" = "linux/arm64" ]; then \
        RID=linux-arm64 ; \
    elif [ "$TARGETPLATFORM" = "linux/arm/v7" ]; then \
        RID=linux-arm ; \
    fi \
    && dotnet publish -c release -o /app -r $RID --self-contained false

# final stage/image
FROM mcr.microsoft.com/dotnet/runtime:5.0-buster-slim
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["./dotnetapp"]

[devedse]

@MichaelSimons Thanks for the elaborate answer. I'll try this later and will comment if it works.

[devedse]

@MichaelSimons , I just updated my dockerfile using your first approach and it works!
https://github.com/devedse/DeveMazeGeneratorCore/blob/master/DeveMazeGeneratorCore.Web/Dockerfile

https://github.com/devedse/DeveMazeGeneratorCore/actions?query=workflow%3Adocker

I do have a few questions:

1. When using your second approach in combination with --self-container true you could run this on any docker image you want right?
2. If yes on the previous question, do you know what the smallest image would be that would work for all architectures?
3. To me it really feels like the second approach has a lot of advantages which eventually results in a smaller image. Is there any disadvantage in doing it this way?

[devedse]

Ok, I actually answered all my previous questions while reading the following post already :smile::
https://andrewlock.net/should-i-use-self-contained-or-framework-dependent-publishing-in-docker-images/

So thanks again for your help.

[devedse]

@MichaelSimons , One last item I can't figure out, hopefully you will be able to help me with this :).

I want to build an image, tag it as latest and a version number. And then push these to the docker hub.
How would I do that?

I currently have this:

docker buildx build -f DeveMazeGeneratorCore.Web/Dockerfile --build-arg BUILD_VERSION=$VERSION --platform linux/arm,linux/arm64,linux/amd64 -t devedse/devemazegeneratorcoreweb --push .

But this only pushes latest as you can see here:
https://hub.docker.com/repository/docker/devedse/devemazegeneratorcoreweb

[devedse]

I managed to solve this by using the following command (apparently you can use multiple tags):

docker buildx build -f DeveMazeGeneratorCore.Web/Dockerfile --build-arg BUILD_VERSION=$VERSION --platform linux/arm,linux/arm64,linux/amd64 -t devedse/devemazegeneratorcoreweb:${{needs.generate_version_number.outputs.build_number}} -t devedse/devemazegeneratorcoreweb:latest --push .