Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionJan Pazdziora (Red Hat)
2018-08-13 09:34:48 UTC
+++ This bug was initially created as a clone of Bug #1615101 +++
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.
Comment 2Jan Pazdziora (Red Hat)
2018-08-13 09:36:16 UTC
I see the same issue on RHEL 7.5 -- docker on RHEL 7.5 and
FROM registry.access.redhat.com/rhel7
and nfs-utils-1.3.0-0.54.el7.x86_64 in the container.
var-lib-nfs-rpc_pipefs.mount: Mount process exited, code=exited status=32
32 == EPIPE.
If that's what was actually returned from the mount system call, that's surprising. (Maybe an strace to confirm this would help?) I'd expect EPIPE on a read or write to a pipefs file but I wonder what it could mean on mount.
Would it be possible to explain (to someone ignorant of docker) what this container looks like from the kernel's point of view? E.g. which kinds of namespaces are the mount process running in? Is it still running as a process that's root in the init namespace?
Oh, sorry, I see, it was actually EACCES: mount: /var/lib/nfs/rpc_pipefs: permission denied. That makes more sense.
Comment 8RHEL Program Management
2021-02-15 07:41:29 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.