Description of problem: When nfs-utils happens to be installed in container image, running systemd in the container shows degraded status due to failed var-lib-nfs-rpc_pipefs.mount. Version-Release number of selected component (if applicable): nfs-utils-2.3.2-1.rc3.fc28.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. Have Dockerfile FROM registry.fedoraproject.org/fedora:28 RUN dnf install -y nfs-utils && dnf clean all ENV container docker ENTRYPOINT [ "/usr/sbin/init" ] 2. Build image: docker build -t systemd . 3. Run the systemd container: docker run --name systemd --rm -d systemd 4. Check things in the container: docker exec systemd systemctl status | grep State 5. Check var-lib-nfs-rpc_pipefs.mount specifically: docker exec systemd systemctl status var-lib-nfs-rpc_pipefs.mount Actual results: State: degraded ● var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System Loaded: loaded (/usr/lib/systemd/system/var-lib-nfs-rpc_pipefs.mount; static; vendor preset: disabled) Active: failed (Result: exit-code) since Sun 2018-08-12 10:31:10 UTC; 56s ago Where: /var/lib/nfs/rpc_pipefs What: sunrpc Process: 29 ExecMount=/usr/bin/mount sunrpc /var/lib/nfs/rpc_pipefs -t rpc_pipefs (code=exited, status=32) Aug 12 10:31:10 0a43512bc7f9 mount[29]: mount: /var/lib/nfs/rpc_pipefs: permission denied. Aug 12 10:31:10 0a43512bc7f9 systemd[1]: Mounting RPC Pipe File System... Aug 12 10:31:10 0a43512bc7f9 systemd[1]: var-lib-nfs-rpc_pipefs.mount: Mount process exited, code=exited status=32 Aug 12 10:31:10 0a43512bc7f9 systemd[1]: var-lib-nfs-rpc_pipefs.mount: Failed with result 'exit-code'. Aug 12 10:31:10 0a43512bc7f9 systemd[1]: Failed to mount RPC Pipe File System. Expected results: State: running The var-lib-nfs-rpc_pipefs.mount not loaded and/or not failing. Additional info: Basically the same happy output when I get when I comment out that "RUN dnf ..." line from the Dockerfile.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The issue is still present with nfs-utils-1:2.3.3-1.rc2.fc29.x86_64.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The issues is still present with nfs-utils-2.4.1-0.rc1.fc30.x86_64.
By adding a --privileged=true flag starting of the container cause all the mounts to work...
I don't think this is the correct solution. The container needs to be runnable unprivileged (or rootless).
*** Bug 1772877 has been marked as a duplicate of this bug. ***
(In reply to Jan Pazdziora from comment #8) > I don't think this is the correct solution. The container needs to be > runnable unprivileged (or rootless). Just curious as to why?
Giving the processes as little privileges as possible is a good thing, isn't it? Note that we do not try to do anything with NFS in the container, so the goal is not to make the mountpoint work or do anything. The nfs-utils package gets pulled in as a dependency for FreeIPA server container image. I believe that in containers, it should not try to setup the .mount by default.
(In reply to Jan Pazdziora from comment #11) > Giving the processes as little privileges as possible is a good thing, isn't > it? Yes! > > Note that we do not try to do anything with NFS in the container, so the > goal is not to make the mountpoint work or do anything. The nfs-utils > package gets pulled in as a dependency for FreeIPA server container image. I > believe that in containers, it should not try to setup the .mount by default. Is there a way to tell when run from a container?
For example ConditionVirtualization=container in the [Unit] section can be used; see systemd.unit(5) for more info. I'm not sure how well it mixes with .mount units though.