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.

Bug 2040674

Summary: podman build can not mount /usr/share/rhel/secrets with NFS storage
Product: Red Hat Enterprise Linux 9 Reporter: Joy Pu <ypu>
Component: podmanAssignee: Ashley Cui <acui>
Status: CLOSED DEFERRED QA Contact: Joy Pu <ypu>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 9.0CC: acui, ajia, bbaude, dwalsh, gscrivan, jnovy, lsm5, mheon, pthomas, tsweeney, umohnani, yujiang
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-04 22:40:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Joy Pu 2022-01-14 13:01:48 UTC 
Description of problem:
podman build can not mount /usr/share/rhel/secrets with NFS storage, it will report "error applying correct labels: lsetxattr ... operation not supported "

Version-Release number of selected component (if applicable):
podman-3.4.5-0.4.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a docker file
FROM quay.io/libpod/testimage:20210610
RUN ls /run/secrets/etc-pki-entitlement

2. build the image with it
# podman build .
STEP 1/2: FROM quay.io/libpod/testimage:20210610
STEP 2/2: RUN ls /run/secrets/etc-pki-entitlement
WARN[0000] error mounting subscriptions, skipping entry in /usr/share/containers/mounts.conf: error applying correct labels: lsetxattr /var/lib/containers/storage/overlay-containers/435e67b9a17fc0ed96bd0c3ae03dca2f4efb8f781fd63bc4ca64c1ba8337ed7b/userdata/run/secrets/etc-pki-entitlement: operation not supported 
ls: /run/secrets/etc-pki-entitlement: No such file or directory
Error: error building at STEP "RUN ls /run/secrets/etc-pki-entitlement": error while running runtime: exit status 1



Actual results:
mount failed during the build process

Expected results:
It can mounted as expected and can be used.

Additional info:
The mount works with podman run:
# podman run quay.io/libpod/testimage:20210610 ls /run/secrets/etc-pki-entitlement
4953058520223425924-key.pem
4953058520223425924.pem
Comment 1 Daniel Walsh 2022-01-14 13:06:00 UTC 
Where is the NFS storage on the /usr/share or the backing store?
Comment 2 Tom Sweeney 2022-01-14 19:15:42 UTC 
Assigning to Ashley for now, but have cc'd Giuseppe too in case he's thoughts.
Comment 3 Daniel Walsh 2022-01-14 19:20:47 UTC 
Not sure this is really a bug.  I don't know where NFS is becoming involved.
Comment 4 Giuseppe Scrivano 2022-01-14 19:39:20 UTC 
it is failing to set the selinux label.  Not sure where we need to fix it (go-selinux or libpod?) and ignore errors if it is ENOTSUP.
Comment 5 Daniel Walsh 2022-01-14 21:02:18 UTC 
Yes I know what the error is, but I want to know what is on an NFS share.  We should not have storage on NFS.  So I would like to know why this is happening.
Comment 6 Daniel Walsh 2022-01-14 21:03:16 UTC 
If this is testing with an NFS server, then the labeling between the NFS client and Server should be supporting NFS Labels, which would allow the labels to work.
Comment 7 Tom Sweeney 2022-01-18 15:44:06 UTC 
Yiqiao can you please verify the labeling please as Dan noted above?
Comment 8 Joy Pu 2022-02-09 17:43:32 UTC 
Test with security_label enabled in NFS.
/nfs/rootful *(rw,security_label,no_root_squash)

And the error message changed to:
podman build .
STEP 1/2: FROM quay.io/libpod/testimage:20210610
Trying to pull quay.io/libpod/testimage:20210610...
Getting image source signatures
Copying blob 9afcdfe780b4 done  
Copying config 9f9ec7f2fd done  
Writing manifest to image destination
Storing signatures
ERRO[0005] Unmounting /var/lib/containers/storage/overlay/af610490dd63a05cee5638238011febe7cd54a8a57582c58fcd726f21159933b/merged: invalid argument 
Error: error mounting new container: error mounting build container "6dd7c55b8137d803d5af2fa2e0e40b17fc67b2d57e139cbd084b7ed4d466736f": creating overlay mount to /var/lib/containers/storage/overlay/af610490dd63a05cee5638238011febe7cd54a8a57582c58fcd726f21159933b/merged, mount_data="nodev,metacopy=on,lowerdir=/var/lib/containers/storage/overlay/l/5UOI5WGPPCBOOBQTIVPGM7NH4Q,upperdir=/var/lib/containers/storage/overlay/af610490dd63a05cee5638238011febe7cd54a8a57582c58fcd726f21159933b/diff,workdir=/var/lib/containers/storage/overlay/af610490dd63a05cee5638238011febe7cd54a8a57582c58fcd726f21159933b/work,context=\"system_u:object_r:container_file_t:s0:c172,c840\"": invalid argument
Comment 9 Tom Sweeney 2023-05-04 22:40:21 UTC 
Closing as I know we've done other internal NFS testing without an issue.  @ypu if this is still an issue, please open a new BZ.
Comment 10 Alex Jia 2023-05-04 23:35:37 UTC 
(In reply to Tom Sweeney from comment #9)
> Closing as I know we've done other internal NFS testing without an issue. 
> @ypu if this is still an issue, please open a new BZ.

@yujiang please help confirm the above question, thanks!