Unable to serve static files using podman with Parallels as backend from shared folder

Hi everyone

I’ve got a somewhat unique question on how to continue debugging, this is probably mainly interesting for the people who know the in- and outs of the bandit http server.

So the situation is as following: I’m using a Mac with the new ARM chips for development. Recently I wanted to have a closer look at containers using podman and check out if I can use them for local development as well. The idea here was to mount my local elixir project folder into the container, so that I could run my editor etc from my native machine and would only use the container for compiling and controlling the elixir version.

However given that using the native option of podman that runs a Fedora Linux using QEMU is just as slow as using docker with the same setup, I decided to try to use the podman remote feature, where you can basically use any Linux machine that you can access using ssh as your “local” podman backend. And in this case I wanted to use a Fedora server hosted in Paralles, given how fast access to the hosts file system is in Parallels.

Now basically this all works as expected (some more setup is required, but that is not really relevant here), with the notable exception that I cannot serve static files like app.js at all. If I try to e.g. fetch the file using curl, even from inside the container, the download never starts and curl gives me an error like this:

curl: (18) transfer closed with 783282 bytes remaining to read

So after some more testing I’ve found out that this only happens on shared folders from my Mac host, but not if I create a new project inside the container itself. In the latter case this works fine.

I’ve now tried to debug this, however I can’t seem to find what kind of debugging I can activate that will help me futher. I’ve tried using the Bandit.Logger.attach_logger() functions, but those do not give any helpfull output. I’ve also tried to add dbg statements in various parts of the Bandit and ThousandIlands packages, however the last place I could trace was the ThousandIsland.Handler.handle_continuation function, which seems to return normally. So what ever happens must be happening later.

Can anyone give me a pointer if I can somehow check if mabye Erlang is unable to write the file to the socket, or something like that?

Thanks already for any help, it would be really nice if I could get this to work :slight_smile:

Some more info from my side, I’ve setup a simple nginx server on the parallels VM and tried to serve the files on the shared folder using that, and I get the same error/problem. So it seems that this is not related to elixir or Erlang in any way, but is a problem with how the shared folders are handled by Parallels.

Thanks anyway!

Hmm, some more info I’ve found. So first, using nginx, I’ve disabled SELinux, though I’m not sure that was really necessary. And after some more digging around, I’ve finally been able to send the file using nginx by setting the sendfile option of nginx to off.

According to the nginx documentation what this does is, it does not load the file into the buffer before sending it, but rather sends it directly from disk.

So the question now is: Is there an option in Bandit or in Erlang that can be used to turn this off as well?

In case anyone finds this in the future and is interested in a possible solution:

After a lot of digging around in the Bandit sources, then the Thousand Island sources, then the :file, :gen_tcp and :socket modules, I think there is no option to do this in Erlang and the BEAM without modifying the actual C bindings to the network stack…

But I did come up with a workaround for local development and written a long blog post about how to set everything up:


Or jump directly here for the actual solution:


A bit offtopic, but https://orbstack.dev has good performance compared to other solutions. It doesn’t run podman but I don’t think that matters for development as the same containers should be able to run on either Podman or Docker.

Thanks, never heard of that. I’ll check it out, though I always prefer to be as close as possible to my production environment regarding tools etc as possible.