NFS 経由でジャンクションされたボリュームを変更した場合、数秒後に変更が元に戻されるように見えます

に適用されます

clustered Data ONTAP

問題

clustered Data ONTAP では、ボリュームは NAS クライアントにフォルダとして表示されます。つまり、クライアントに表示される一部のフォルダでは、クライアントがフォルダにアクセスすると、クライアントは代わりに別のボリュームにリダイレクトされます。

これらのリダイレクト「フォルダ」はジャンクションパスと呼ばれます。vol showCLI からコマンドを使用すると、ボリュームのジャンクションパスを表示できます。
::>vol show -fields junction-path

上記のコマンドは、クラスタ内のすべてのボリュームのジャンクションパスを表示します。

また、 System Manager の場合、 SVM ストレージの下のネームスペース領域にある各ボリュームのパスの列にボリュームのジャンクションパスが表示されます。ボリュームのジャンクションパスは、管理者が CLI を使用して変更することも、 System Manager などのツールを使用して変更することもできます。

前述したように、これらのジャンクションパスはフォルダとして表示されるため、実際のフォルダと同様に、これらのジャンクションパスを使用して同じ操作を実行することもできます。たとえば、 NFS または CIFS を使用すると、権限や所有権の変更、 ACL の変更、これらのジャンクションパス上および内部データ上でのグループの変更を行うことができます。NFS または CIFS では、ジャンクションパスの名前変更や削除は実行できません。名前変更や削除（作成など）を実行するには、クラスタへの管理アクセスが必要になり、 CLI や管理ツールを使用して実行する必要があります。

NFS 経由のジャンクションパスで処理を実行すると、ネットアップクラスタからクライアントに関連するボリュームとそのファイルシステム ID に関する情報が提供され、変更が関連するボリュームに正しく伝播されます。

一部の特定のバージョンの Linux ディストリビューション（ RedHat 6.3 や Debian 7.0 など）にバグがあると、これらのバージョンを実行しているクライアントはlschownchmodchgrp、ボリュームジャンクション上の NFS 上で、、、または操作（その他）を試みたときにファイルシステム情報を検索しないようになります （ボリュームにリダイレクトされるフォルダ）。
その結果、クライアントは処理をサイレントに中断し、変更処理（ setattr ）をユーザから要求された場合にネットアップクラスタに実際に送信しないため、変更は行われません。
ただし、クライアント/proc/mounts が関連するマウントで属性キャッシュを有効にしている場合（クライアントでは NOAC ではなく関連フラグが AC である場合）、クライアントはこのキャッシュに関連する変更を入力し、最初に変更が成功したように見えます。その後フォルダに設定された権限のリスト（アクセスキャッシュがタイムアウトしたあと）には、変更を試みる前に設定が表示されます。

問題の例：

root@xela:[~] # mount -o noac,vers=3 10.61.85.219:/ /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