[POSTPONED] Provide Docker ARM Image: Function not implemented exception when launching via docker-compose

I have…

  • [ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [X] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

App launched via docker-compose-noproxy.yml: squidex container failing to launch.
Error is:
Unhandled exception. System.IO.IOException: Function not implemented
NB. I have updated the docker-compose to use mongo latest to bypass exit code 62 with unsupported version

Expected behavior

App launches without error

Minimal reproduction of the problem


  • [X] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: [VERSION]


  • [ ] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge


Is it docker for Windows? I just found this: https://stackoverflow.com/questions/63493884/system-io-ioexception-function-not-implemented-in-createhostbuilderargs-buil

I’m docker for mac, I performed the pruning/restart which resolved my mongo issue so I was able to use the docker-compose exactly as cloned. Still get the same issue for the Squidex container however

Hey, I found this: https://github.com/docker/for-mac/issues/5328

When running x86/amd64 code in a container on M1 the binaries are emulated with qemu. The emulation is not perfect and it can go wrong – I believe this is one of those times.

The ideal solution in terms of reliability and performance would be to have a native arm64 image.

I think this explanation makes sense. Dotnet core provides a base image for arm64, but I am not sure which other dependencies might fail. I cannot implement this, because I do not have a mac available and can therefore not test it, but PRs are very welcome.

I have therefore changed this topic to a feature request.

1 Like

Good catch I’m using an M1 chip. I’ll try a build with different base image

1 Like

Have you tried it? Does it work?

Hey, currently we’re facing the same problem with our M1 MacBooks.

As I said before, It should be relatively straight forward to provide another Dockerfile for ARM and then add this to the CI. The cache should do the rest.

The problem is, that I cannot test it, therefore I do not want to do it myself.

1 Like

You only need a copy of the dockerfile and change the base image to an ARM version:

And then add it to Github actions ofc.

1 Like

Thanks for the fast reply! I can test this and open a PR when i have time.

1 Like

Hey Sebastian,
I have freshly cloned the Squidex project (master) and tried to build the Docker image with the build.sh file. The first stage went through successfully, but in the 2nd stage, where the frontend builds, i get an error as shown in the screenshot. It looks like it has a problem with the npm run test:coverage command. Do you know this error, or did I forget to do something beforehand?

Apologies I also faced the same issue, and haven’t had chance to delve further

I guess you have to change the base image. For the frontend this is used: https://github.com/buildkite/docker-puppeteer/blob/master/Dockerfile

I guess chrome can not start on arm. Not sure.

The frontend base image uses google-chrome-stable which is not available for arm64, but we can use Chromium. I got this to work by changing docker-puppeteer Dockerfile lines 9 to 17 (inclusive) to:

&& apt-get install -y chromium fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 --no-install-recommends \

Rebuild that image.

Then, change the squidex Dockerfile stage 2 FROM (line 45) to refer to the rebuilt frontend image, and below that add the line ENV CHROME_BIN=/usr/bin/chromium , then rebuild this image as well which should now go through without error including the Angular tests.

Finally, update your docker-compose.yml to point to the rebuilt Squidex image.


For what it’s worth, as a workaround: you should be able to run a x86 image on ARM by passing the platform param in the docker command when running it, and it should work as expected ( in most cases )

This is a known issue on ARM with container ( docker ) images. see: https://forums.docker.com/t/run-x86-intel-and-arm-based-images-on-apple-silicon-m1-macs/117123/5

in the above discussion, they use linux/amd64 because that target platform was built, and pushed to dockerhub, but I’ve had a lot of success with using platforms that you’d assume wouldn’t work, like linux/amd64 ( I think this works because of rosetta, but I can’t be sure of that, it’s just my experience on a M1 ). So, I suggest choosing the closest published platform when choosing to do this, which is shown here:

and there is only the one platform, linux/amd64, so maybe try adding --platform linux/amd64 in all of the docker commands? I haven’t tried this myself, it may or may not work, just adding my personal experience.

1 Like


Any update on planned support for M1 MacBooks?
Anything I can do to help test this

I still do not have a mac, so I cannot really test. PRs are very welcome.

1 Like

I have read that .net7 images are now multiplatform images, so this simple line could actually fix the problem now:

1 Like

That would be great :slight_smile:
I have a Mac, so I can test. Is there a command I need to run for docker build?

It does not work yet, I am going from error to error. The last one is this: