To Reproduce Steps to reproduce the behavior:

It has the similar issue as https://issues.redhat.com/browse/OSPRH-13968

Customer having RHOSP  Minor Upgrade from 17.1.2 to 17.1.6, During controller upgrade, existing NFS mount went in "Stale file handle"

Customer already applied the hotfixes but still not working

root@NFS-Jpe6b:/etc/netplan# mount -t nfs -v 172.27.0.10:/volumes/_nogroup/4003b626-1d16-4a88-ab71-da28b8bac94b/1017d576-ae8a-4cc8-8fdb-6d7f452638e1 /NFS
mount.nfs: Stale file handle
 
root@NFS-Jpe6b:/etc/netplan# mount -t nfs -v 172.27.0.10:/volumes/_nogroup/4003b626-1d16-4a88-ab71-da28b8bac94b/1017d576-ae8a-4cc8-8fdb-6d7f452638e1 /NFS
mount.nfs: timeout set for Mon May 12 01:27:17 2025
mount.nfs: trying text-based options 'vers=4.2,addr=172.27.0.10,clientaddr=172.27.3.23'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=172.27.0.10'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=4.2,addr=172.27.0.

Expected behavior

• NFS Mounts should work 

Device Info (please complete the following information):

• OS Version: RHEL9
• RHOSP17.1.6

Bug impact

• Although customers were able to mount the NFS shares, data from these shares was not accessible on their VMs, preventing them from reading or writing any files. This disrupted their ability to access critical data and impacted their business operations.

Known workaround

• Cu  applied WA to remove and add the ACLs which resolved issue

• https://access.redhat.com/solutions/7051579 

Additional context