Bug 1305488
| Summary: | nfsidmap: Failed to add child keyring: Operation not permitted | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | michal novacek <mnovacek> | ||||
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Filesystem QE <fs-qe> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.8 | CC: | ckloiber | ||||
| Target Milestone: | rc | Flags: | ckloiber:
needinfo?
|
||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-02-13 13:56:07 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: | |||||||
| Attachments: |
|
||||||
*** This bug has been marked as a duplicate of bug 1303877 *** bug 1303877 is marked as PRIVATE. Please update this public bug, or permit access to the listed bug. |
Created attachment 1122150 [details] 'pcs cluster report' output Description of problem: I'm recently getting 'nfsidmap[4540]: Failed to add child keyring: Operation not permitted' with NFS cluster HA testing. I found out this problem while testing nfs (re-)locking of file while nfs server is moving from node to node. Version-Release number of selected component (if applicable): nfs-utils-1.2.3-68.el6.x86_64 kernel-2.6.32-613.el6.x86_64 How reproducible: always Steps to Reproduce: 1. have running pacemaker ha nfs server 2. on the client node outside of cluster mount nfs from server and exclusively lock file 3. move nfs server to another node Actual results: long time to determine lock acquisition/denial + failed to add... Expected results: short time to acquire/deny Additional info: It seems that acquiring/denying lock takes up to 10s where it previously was less than 1s (RHEL-6.8-20160205.n.0 snapshot).