NFS Server – Known Issues / Restrictions

Top level NFS resource hierarchy uses the switchback type of the hanfs resource

The switchback type, which dictates whether the NFS resource hierarchy will automatically switch back to the primary server when it comes back into service after a failure, is defined by the hanfs resource.

Some clients are unable to reacquire nfs file locks

When acting as NFS clients, some Linux kernels do not respond correctly to notifications from an NFS server that an NFS lock has been dropped and needs to be reacquired. As a result, when these systems are the clients of an NFS file share that is protected by LifeKeeper, the NFS locks held by these clients are lost during a failover or switchover.

When using storage applications with locking and following recommendations for the NFS mount options, SPS requires the additional nolock option be set, e.g. rw,nolock,bg,hard,nointr,tcp,nfsvers=3,timeo=600,rsize=32768,wsize=32768,actimeo=0.

NFS v4 changes not compatible with SLES 11 nfs subsystem operation

The mounting of a non-NFS v4 remote export on SLES 11 starts rpc.statd. The start up of rpc.statd on the out of service node in a cluster protecting an NFS v4 root export will fail.

Solution: Do not mix NFS v2/v3 with a cluster protecting an NFS v4 root export.

NFS v4 cannot be configured with IPv6

IPv6 virtual IP gets rolled up into the NFSv4 heirarchy.

Solution: Do not use an IPv6 virtual IP resource when creating an NFSv4 resource.

NFS v4: Unable to re-extend hierarchy after unextend

Extend fails because export point is already exported on the target server. A re-extend to server A of a NFS v4 hierarchy will fail if a hierarchy is created on server A and extended to server B, brought in service on server B and then unextended from server A.

Solution: On server A run the command “exportfs -ra“ to clean up the extra export information left behind.

File Lock switchover with NFSv3 fails on some operating systems

Failover file locks with NFSv3 during resources switchover/failover does not work on the operating systems listed below. Lock failover with NFSv3 is currently not supported on these OS versions.

• RHEL7, CentOS7, OL7
  
  
• RHEL6, CentOS6, OL6
  
  
• SLES12
  
  
• SLES11
  
  

The Oracle Recovery Kit does not support NFSv4

The Oracle Recovery Kit supports NFSv3 for shared database storage. NFSv4 is not supported at this time due to NFSv4 file locking mechanisms.

Stopping and starting NFS subsystem adversely impacts SIOS Protection Suite protected NFS exports.

If the NFS subsystem (/etc/init.d/nfs on Red Hat or /etc/init.d/nfsserver on SuSE) is stopped while SIOS Protection Suite for Linux is protecting NFS exports, then all SIOS Protection Suite for Linux protected exported directories will be impacted as the NFS stop action performs an unexport of all the directories. The SIOS Protection Suite for Linux NFS quickCheck script will detect the stopped NFS processes and the unexported directories and run a local recovery to restart the processes and re-export the directories. However, it will take a quickCheck run for each protected export for the SIOS Protection Suite NFS ARK to recover everything. For example, if five exports are protected by the SIOS Protection Suite for Linux NFS ARK, it will take five quickCheck runs to recover all the exported directories the kit protects. Based on the default quickCheck time of two minutes, it could take up to ten minutes to recover all the exported directories.

Workaround: Do not stop the NFS subsystem while the SIOS Protection Suite NFS ARK is actively protecting exported directories on the system. If the NFS subsystem must be stopped, all NFS resources should be switched to the standby node before stopping the NFS subsystem. Use of the exportfs command should also be considered. This command line utility provides the ability to export and unexport a single directory thus bypassing the need to stop the entire NFS subsystem.