Kernel panic trying to mount a volume

I’m trying mount a volume to /var/lib/podman/.local/share/containers and it fails with this:

thread 'main' panicked at 'could not create directory /var/lib/podman/.local/share/containers: ENOENT: No such file or directory', src/bin/init/main.rs:594:21

That’s interesting. It sure seems like the volume didn’t get mounted. What does the [mount] section in your fly.toml look like?

[[mounts]]
  destination = "/var/lib/podman/.local/share/containers"
  source = "containers"

Could it have anything to do with the long path?

I got it to work by creating the directory in the Dockerfile first, but its worked for me before without that step.

It might just be that the directory tree leading up to the mount destination may not exist and we’re not creating it for you.

I’ll take a look at this.

For now can you try creating all directories for that destination path in your Dockerfile?

1 Like

Yep I ran mkdir -p in my Dockerfile. It’s strange because I haven’t needed to do that before. Could it also have somthing to do with the hidden directory in the path?

I don’t think the hidden directory is a problem. However, if the whole path to the directory wasn’t created, then it would fail. I’m playing with doing the equivalent of mkdir -p, but I don’t love doing that automatically for users. Our implementation would set permissions to 755 and ownership to the same USER specified in the Dockerfile. These are the most sane defaults I could come up with, but it may not be what some images want.

Ah I get it. So if its a path right at the root, then it’ll work. I just tried mounting a volume at a deep path using docker (-v test:/this/is/a/really/long/path) and it essentially does a mkdir -p with 755 permissions. I guess that’s what I expected to happen with fly too.

If Docker does that, I think we’ll do that too for least surprise! I should be able to deploy the fix for that this week. Thanks for testing it out on Docker :slight_smile:

Hey @jerome did this get fixed? Don’t mean to be pushy but I’m curious.

@blanst t’s fixed in a branch for our init. I just pushed it everywhere (along with the UID fix). It seems to work properly (at least the mkdirp up to the mount target).

Yep works now @jerome

1 Like