While testing nfs-ganesha with Windows clients using NLM I ran into an issue
related to the NLM SHARE call, which Windows utilizes on mounts made with
locking enabled (the default; "-o nolock" works around the issues).
ganesha is granting an exclusive write NLM SHARE call but then denying a
subsequent WRITE (by the share owner). Someone else reported this on the list,
but the threaded ended without resolution:
https://sourceforge.net/p/nfs-ganesha/mailman/message/35006656
I tracked this particular issue down to ganesha incrementing the v4 share count
for shares that result from an NLM SHARE call. Since NLM SHARE is inherently an
NFSv3(,2,1) operation, the v4 count should not be incremented on this code path
(state_nlm_share). Note that this is specifically an NLM path (i.e., NFSv3 and
below); NFSv4-related share operations are performed via
state_share_{add,remove,upgrade,downgrade} which do correctly update the v4
count.
The patch below addresses this issue. Issue was found, fixed, and verified on
V2.2; patch below is against -next.
With this change in place I am able to successfully access a ganesha server
from Windows clients without using the "nolock" mount option.
--Adam
When recording an NLM SHARE state for a file, do not set the
NFSv4 flag as this will erroneously cause denial of future NFSv3 writes
to that file. NLM SHARE is inherently an NFSv3 operation and as such
should not use an NFSv4 flag. This fixes the ability of Windows
clients to write to files when the "-o nolock" flag is not in use.
---
src/SAL/state_share.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/SAL/state_share.c b/src/SAL/state_share.c
index 4f46cef..c11c61c 100644
--- a/src/SAL/state_share.c
+++ b/src/SAL/state_share.c
@@ -992,7 +992,7 @@ state_status_t state_nlm_share(struct fsal_obj_handle *obj,
old_share_deny,
share_access,
share_deny,
- true);
+ false);
/* Get the updated union of share states of this file. */
new_entry_share_access = state_share_get_share_access(obj->state_hdl);
@@ -1017,7 +1017,7 @@ state_status_t state_nlm_share(struct fsal_obj_handle
*obj,
share_deny,
old_share_access,
old_share_deny,
- true);
+ false);
remove_nlm_share(state);
@@ -1100,7 +1100,7 @@ state_status_t state_nlm_unshare(struct fsal_obj_handle
*obj,
old_share_deny,
new_share_access,
new_share_deny,
- true);
+ false);
/* Get the updated union of share states of this file. */
new_entry_share_access = state_share_get_share_access(obj->state_hdl);
@@ -1127,7 +1127,7 @@ state_status_t state_nlm_unshare(struct fsal_obj_handle
*obj,
new_share_deny,
old_share_access,
old_share_deny,
- true);
+ false);
LogDebug(COMPONENT_STATE, "do_share_op failed");
goto out;
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
