VDB NFS Mount Permissions Changed (KBA5414)
KBA
KBA# 5414
Issue
VDB mount permissions have changed against one or more of the NFS mount directories. Typically, the first indication of an issue is Snapshots will fail for the affected VDB. Depending on the affected NFS mount, this can lead to a loss of access to the VDB.
Listing the mount point permissions for the affected VDB on the Target host show user and group ownership are incorrect:
/mnt/provision/VDB_name-> ls -lrt total 3 drwxr-x--x 2 65433 wheel 2 Nov 20 05:02 datafile drwxr-x--x 2 65433 wheel 2 Nov 20 05:02 external drwxr-x--x 2 65433 wheel 2 Nov 20 05:02 archive drwxr-x--x 2 65433 wheel 2 Nov 20 05:02 temp drwxr-x--- 3 oracle oinstall 3 Nov 20 05:02 script
In this example we see that the only NFS mount with the original (correct) permissions is 'script'. The others have changed to 65433/wheel indicating they are no longer mounted.
Prerequisites
- The Target environment OS is Linux - Version Oracle Linux 6.7 with Unbreakable Enterprise Kernel [4.1.12] or later.
- The mtab file still lists the file system as mounted (even though it is not).
- There is no sudo entry in the secure file for a umount operation on that VDB file system which rules out a Delphix operation. (Delphix needs sudo permissions to umount file systems, and sudo operations are logged in /var/log/secure by default).
- Although not always the case another symptom of this issue is that not all of the VDB mount points are affected (as in the example above).
Applicable Delphix Versions
- Click here to view the versions of the Delphix engine to which this article applies
-
Major Release
All Sub Releases
6.0 6.0.0.0 5.3 5.3.0.0, 5.3.0.1, 5.3.0.2, 5.3.0.3, 5.3.1.0, 5.3.1.1, 5.3.1.2, 5.3.2.0, 5.3.3.0, 5.3.3.1, 5.3.4.0, 5.3.5.0 5.3.6.0, 5.3.7.0, 5.3.7.1 5.2 5.2.2.0, 5.2.2.1, 5.2.3.0, 5.2.4.0, 5.2.5.0, 5.2.5.1, 5.2.6.0, 5.2.6.1 5.1
5.1.0.0, 5.1.1.0, 5.1.2.0, 5.1.3.0, 5.1.4.0, 5.1.5.0, 5.1.5.1, 5.1.6.0, 5.1.7.0, 5.1.8.0, 5.1.8.1, 5.1.9.0, 5.1.10.0
5.0
5.0.1.0, 5.0.1.1, 5.0.2.0, 5.0.2.1, 5.0.2.2, 5.0.2.3, 5.0.3.0, 5.0.3.1, 5.0.4.0, 5.0.4.1 ,5.0.5.0, 5.0.5.1, 5.0.5.2, 5.0.5.3, 5.0.5.4
4.3
4.3.1.0, 4.3.2.0, 4.3.2.1, 4.3.3.0, 4.3.4.0, 4.3.4.1, 4.3.5.0
4.2
4.2.0.0, 4.2.0.3, 4.2.1.0, 4.2.1.1, 4.2.2.0, 4.2.2.1, 4.2.3.0, 4.2.4.0 , 4.2.5.0, 4.2.5.1
4.1
4.1.0.0, 4.1.2.0, 4.1.3.0, 4.1.3.1, 4.1.3.2, 4.1.4.0, 4.1.5.0, 4.1.6.0
4.0
4.0.0.0, 4.0.0.1, 4.0.1.0, 4.0.2.0, 4.0.3.0, 4.0.4.0, 4.0.5.0, 4.0.6.0, 4.0.6.1
3.2
3.2.0.0, 3.2.1.0, 3.2.2.0, 3.2.2.1, 3.2.3.0, 3.2.4.0, 3.2.4.1, 3.2.4.2, 3.2.5.0, 3.2.5.1, 3.2.6.0, 3.2.7.0, 3.2.7.1
3.1
3.1.0.1, 3.1.1.0, 3.1.2.0, 3.1.2.1, 3.1.3.0 , 3.1.3.1, 3.1.3.2, 3.1.4.0, 3.1.5.0, 3.1.6.0
3.0
3.0.0.3, 3.0.0.4, 3.0.1.0, 3.0.1.1, 3.0.1.2, 3.0.1.3, 3.0.2.0, 3.0.2.1, 3.0.3.0, 3.0.3.1, 3.0.4.0, 3.0.4.1, 3.0.5.0, 3.0.6.0, 3.0.6.1
Resolution
To resolve this problem, engage Oracle and reference the following document:
EK4 dropping NFS shares intermittently due to kernel invalidating dentrys that aren't actually invalid. (Doc ID 2402239.1).
This issue is caused by a known defect with nfs4 dentrys being invalidated in the UEK 4 kernel, even when they are valid.
Troubleshooting
Related Articles
The following articles may provide more information or related information to this article:
- N/A