Article summary
Last summer, I started encountering an issue with my Docker containers while performing local development. I began occasionally seeing the phrase “Permission denied” in my container logs several hundred times before the container would refuse to start. Initially, this wasn’t a huge issue for me, as I could just click the “Restart” button a few times, and my container would come alive. However, as time went on, this became much more difficult to carry out, as the container would not start unless I recreated it.
Some time ago, I wrote a post about ensuring Rosetta was enabled for emulation’s sake. This was the first thing I considered, and I confirmed my Rosetta was turned on. The issue at hand was entirely different, and, unfortunately, it would take me many months to diagnose.
Why “Permission denied”?
If you were having the same issue as me, you likely have a docker.yml that looks something like this:
My initial thought was that there was something wrong with the image (SQL Edge). To test this, I tore down all my containers, images, and volumes and remade everything. This seemed to solve the problem temporarily. Nevertheless, a few days later, the “Permission denied” error cropped up again. I was peeved at the idea, but re-initializing my docker containers appeared to enable me to continue coding. So, I let it be – again.
Eventually, the issue reached a stage where the container flat-out refused to start. At this stage, even remaking the container wasn’t working, so I began to seek answers. Many of my peers advised me to update my Mac version. To be fair, I was running a (comparatively) very old version of the Mac OS, so I decided to try that first. Following the update, ironically, the container stopped logging “Permission denied” altogether and instead simply crashed. Deleting the container again and rerunning the docker compose up command got me back my logs, but it still failed to start. Obviously, that wasn’t the solution I was looking for.
I then thought that uninstalling and reinstalling Docker in its entirety might solve my problem. I surmised that maybe my application corrupted somehow? Multiple reinstalls later and my issue still existed.
What Next?
I went digging. I Googled the “Permission denied” error and its relevant code, and found the same advice: update Mac OS, check your permissions, reinstall Docker, etc. None of this solved the problem at hand. I grew frustrated. At what point would I get my work done?
I had all but resigned to drop my current story. I was working on some major API changes, and if I was unable to run my container locally, I couldn’t do anything. In the process of this meeting, I thought to do some research into SQL Edge. I went onto the Microsoft website to find multiple messages. One message stated that SQL Edge was deprecated and would be removed entirely towards the end of 2025.
The other mentioned that SQL Edge 2.0.0 no longer supported ARM64 platforms. Great news (not really)! But I was using a version earlier than that, so why were my containers still crashing? This was only half the story.
On the Google results page, below the SQL Edge result, was a Github thread. For several months, multiple people had been experiencing the same problem as I had. The advice pointed the blaming finger at Microsoft for choosing to abandon the ARM64 platform, effectively isolating Mac developers. I found my diamond in a comment that further explained where the “Permission denied” error occurred. Docker, beginning from version 4.33, had updated its Linux kernel version to 6.10 — a version that SQL Edge was not compatible with.
The Solution
The solution was to downgrade Docker to 4.32, or change the SQL image to MSSQL 2022, which works with Rosetta virtualization. I had found my full explanation for the “Permission denied” error and completed my quest to solve the problem. I could work again.
Simply change the image from Azure SQL Edge to mssql 2022, tear down your old container, and run docker compose up . That’s it.