Skip to main content
NetApp Knowledge Base

When modifying a junctioned volume over nfs, the change seems to revert after a few seconds

Last Updated:

Applies to

Clustered Data ONTAP


In Clustered Data ONTAP, volumes are presented as folders to NAS clients. This means that for some folders shown to clients, when a client accesses the folder, the client is redirected to a different volume instead.

These redirecting 'folders' are known as junction paths. The vol show command from the cli can be used to show the junction paths for volumes.
::>vol show -fields junction-path

The above command will list the junction paths of all the volumes in a cluster.

Alternatively, in System Manager, the junction paths of volumes can be seen in the path column for each volume in the namespace area under vserver storage. The junction path of a volume can be modified by an administrator through the cli, or through tools such as System Manager.

As mentioned before, these junction paths present themselves as folders; consequently many of the same operations can be performed with these junction-paths as can be performed with actual folders. For example, through NFS or CIFS, permission and ownership changes can be made, ACLs can be modified, and group changes can be made on these junction paths, as well as on the data inside them. Keep in mind that junction paths cannot be renamed or deleted by clients though NFS or CIFS, rename or removal operations (like their creation) require administrative access to the cluster to be done successfully, and is done over the cli or with management tools.

When performing an operation on a junction path over NFS, the NetApp cluster will present the client with information about the relevant volume and its file system id, so changes are propagated correctly to the relevant volume.

A bug in some specific versions of various Linux distributions (for example, RedHat 6.3 and Debian 7.0) causes clients running these versions to avoid looking up the file system information when attempting an lschownchmod or chgrp operation (amongst others) over NFS on a volume junction (the folder that redirects to the volume).
As a result, the client silently interrupts the operation and no change operation (setattr) is actually sent to the NetApp cluster if requested by a user, and consequently no changes are made.
However, if the client has the attribute cache enabled on the relevant mount (the relevant flag is ac as opposed to noac, as can be seen in /proc/mounts on the client), the client will populate this cache with the relevant change, making it seem like the change was successful at first. Any later listing of the permissions set on the folder (once the access cache has timed out) will show the settings prior to the modification attempt.

Example of the issue:

root@xela:[~] # mount -o noac,vers=3 /mnt   #<-- mounting with noac to avoid a poisoned client cache and see the immediate silent failure
root@xela:[~] #cd /mnt
root@xela:[/mnt] #ls -l
total 12
drwxrwxrwx 2 root    daemon 4096 Jan 29 10:55 junction
root@xela:[/mnt] #chmod 755 junction
root@xela:[/mnt] #ls -l
total 12
drwxrwxrwx 2 root    daemon 4096 Jan 29 10:55 junction2    #<-----chmod change did not take effect



Registered NetApp customers get unlimited access to our dynamic Knowledge Base.

New authoritative content is published and updated each day by our team of experts.

Current Customer or Partner?

Sign In for unlimited access

New to NetApp?

Learn more about our award-winning Support