Support type=bind mounts for rootless named volumes

[JessiAuro]

/kind feature

It's possible to create a named volume that points to an arbitrary location like this:

podman volume create -o type=bind -o device=/data mydata

This can be useful to avoid having to type a long path for multiple containers that need to access the same volume and makes commands/systemd units/etc that reference the volume more portable.

However, attempting to use such a volume (with podman version 3.4.0) with a rootless container results in the following error:

Error: error mounting volume mydata for container [...]: cannot mount volumes without root privileges: operation requires root privileges

According to the docs:

Using volume options other then the UID/GID options with the local driver requires root privileges.

My understanding is that such a bind mount should be possible for a non-root user as long as permissions are set correctly, so it would be nice if podman would make an exception in this case.

[Luap99]

You can create bind mounts on container creation, e.g. podman create -v /path/to/source:/target ....
I do not think it makes sense for podman volume to mange bind mounts.

[JessiAuro]

The point is to avoid having to specify the full path at container creation. It can be easily worked around, sure, but it's something that can already be done with docker/root podman without issue. The operation doesn't "require root privileges" as the error says.

[rhatdan]

@mheon @Luap99 I think this should be supported, the issue is probably we are attempting to mount while not in the user namespace.
@mheon WDYT?

[mheon]

Code's already all there, and should work as root. We just need to teach the mount code for volumes to understand that certain types of mount (fuse, bind, tmpfs) are allowed in the rootless user namespace, as opposed to what it does now, which is assume they are only possible as root.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[stellarpower]

And I was just about to open a new issue if it didn't already exist! You guys sure work fast :D.

@rhatdan, is this likely to make it into a new release soon then? I have an MRP as a sample/testing.:

rootless@machine ~> mkdir /tmp/SourceMount{Docker,Podman}

rootless@machine ~> docker volume create --driver local --opt 'type=none' --opt 'device=/tmp/SourceMountDocker' --opt 'o=bind' TestVolumeDocker
TestVolumeDocker
rootless@machine ~> docker run --rm -it -v TestVolumeDocker:/t ubuntu:focal
root@fa7ccee47cfd:/# touch /t/hello
root@fa7ccee47cfd:/# exit

rootless@machine ~> podman volume create --driver local --opt 'type=none' --opt 'device=/tmp/SourceMountPodman' --opt 'o=bind' TestVolumePodman
TestVolumePodman
rootless@machine ~> podman run --rm -it -v TestVolumePodman:/t ubuntu:focal
Error: error mounting volume TestVolumePodman for container acc74a08b0fb9e4e38101da63413f2577ac15f9f1b579acc112a3ded25a6f0d3: cannot mount volumes without root privileges: operation requires root privileges
rootless@machine ~>

Whilst it seems a frivolity, this is actually a real-world problem in my current setup. Granted, the root cause may be somehting else and my fault, but I seem to recall the same when I did an equivalent setup using docker. I also copied from the maintainers' compose yaml.

I have a somehwat complicated compose setup where an nginx serves static content and forwards the dynamic content to an FPM container. I want to catch the different configs and keep separately, for backup purposes, so I have multiple volumes nested under the root:

- root
  - configs
  - themes
  - data
  - apps
  * file1
  * file2
etc.

Trying to use bind mounts in this scenario I believe is causing race conditions between the nginx webserver container and the PHP FPM. Why, I don't exactly know. The nginx server is logging that it can't stat the files, even though if I exec in they're there, and writable. I have tried mounting read-only in the webserver, but I do seem to remember something spooky just like this about two years ago when I first deployed this setup using docker, when I knew much less what I was doing. In the end I made the volumes to be named, but bind-mounted to local directories, so I had the best of both worlds. I think there must have been a good reason for this, as it complicates matters - ergo, without them, I think I hit the same problem with docker. I have some déjà vu at least. As with podman currently, using a named volume makes the problem go away, but without the bind mount the backng storage is a nuisance, and so a named bind-mount allowed me to store the precious data both conveniently and on my ZFS dataset so that I could snapshot and backup like a breeze.

I'd also suggest maybe a bit more in the docs that explains what the local driver is doing - I'm guessing that it was assuming I was trying to mount as if calling the normal mount command, and thus as in the PRs above, hadn't sussed out that this was actually a permissable special case mount as non-root.

[rhatdan]

It will be in Podman 4.0 which should get RC2 today on Monday. Podman 4 final will be released by Feb 15.

[mheon]

RC2 today, actually.

[stellarpower]

Fab, will RC2 be available as a built binary?

Or end of the day, of all the projects to have a good containerised build process, I'm guessing podman itself should be one! So don't anticipate it should be too hard to do myself.

[rhatdan]

It will get built into a Fedora RPM if that is what you meant.

[stellarpower]

We're on Debian I think, Ubuntu if not. A static binary would be fine, just wondering what's the quickest way to grab it and try it out over the weekend. Am currently using the nix recipe inside a container, will see how it goes.

Cheers

[rhatdan]

@lsm5 What is going on for these distros, Anything?

[stellarpower]

I had a small nightmare with the static nix build, it is refusing to build dependencies inside a container itserlf. As we speak am gonna see if I can build from source with the Suse repo's 3.4 source package before Ithrow in the towel fully.

[stellarpower]

That was relatively painless :D. Certainly not the hours of failing tests the nix was. I fudged it, didn't bump versions properly, and just extracted to /usr/local so we can test, but am happy to share binary package if anyone's desperate.

I had to pull the recipe using apt sources, it'd be nice if the debian directory were checked in or a link provided in the build docs, so it'd be easy enough to browse how it builds from source. If it hasn't been modified in anticipation of 4.0 I'll happily contribute, if I can find where it is.