ZFS+acltype+fuse-overlayfs, Operation Not Supported #11213
Comments
|
I can also reproduce this issue on Fedora 34 and podman 3.2.3. However, I am not seeing this issue if I run podman as root. |
|
Could this be a fuse-overlayfs issue? |
|
@rhatdan would there be something I could do to test that? I can confirm, this seems to only manifest when I have a user home directory, and the associated bind mounts, on a ZFS dataset. I moved all my applications temporarily to mdadm+xfs and everything comes up as expected. This is a bit of a pickle. I realize that ZFS is out of tree and all that, also not golden path for RH or Fedora. Wondering if I should register an issue upstream with that project or if this is within the podman ecosystem? |
|
To report back in:
I'm not sure if this project is the right upstream to be reporting in, would there be a better place to report (or link) and attempt to characterize this issue further? I've got a system that I can rapidly test things on if there are any suggestions. |
|
Alright, that doesn't make much sense... Under the hood, those should both be kernel bind-mounts, with almost identical options. Can you include examples of working |
I can't confirm this. I'm using podman with fuse-overlayfs on Ubuntu and my home directory is ZFS. |
|
I'm not sure if this is exactly related, but this seems like a good place to put this for now, spent most of my day trying to figure this out after updating my system. I started to get this error with some containers but not all: and stuff like when trying to run containers. After trying around for a bit, I found out that specifically the make home directory part of Tried my way through podman versions back to 2.2.0, and it was the same everywhere. The only thing that got updated recently was fuse-overlayfs, from 1.5 to 1.7.1. I was able to narrow the cause down to this commit: containers/fuse-overlayfs@dd7e124, which enabled POSIX ACLs. But as it turns out my zfs pools on gentoo had Oddly enough, I'm also encountering this on my server where I run buildah in cri-o containers for CI, where the zfs pools already have this property set. Here the |
|
opened a PR for fuse-overlayfs so it is possible to disable ACLs: containers/fuse-overlayfs#323 |
Trying to pull this apart:
|
|
Actually re-reading, it sounds like |
|
Was able to reproduce with Thanks @maxaudron for chiming in, this has been making me sad for a while. @giuseppe out of the box podman and fuse-overlayfs will be wanting ACL(s) right? So if this were to be a tombstone for people to find they could do the following:
|
andrewgdunn
changed the title
|
@storrgie yes, by default ACLs are enabled. Is there anything more that should happen in Podman/fuse-overlayfs or can we close this issue now? |
|
We can close it, just wanted to have it be a completely understood phenomena. Thanks! |
github-actions
bot
added
the
locked - please file new issue/PR
I've been happily cruising along using Fedora+ZFS+Podman to run a variety of services. I am deploying these in what I think is the recommended pattern based on interacting with podman for a little while now. Some other contexts:
This appears to have manifested after a recent update, all container deployments are impacted on this system.
Here is an example of one of the deployments:
Assume that I have created a proper file at
~/.database.envwith envars in it.From what I gather this is:
~/databasedirectory to 777hedgedocusers home directory (I removed this user and the home directory to start fresh)I immediately downgraded to podman 3.1.0 to see if that was the case as well, but that behaves the same way.
I'm actually super stumped on this one. Maybe it's ZFS?
The text was updated successfully, but these errors were encountered: