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
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
@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).