There is an undocumented convention (verified by reviewing network traces from a NetApp filer and a Solaris NFS server) where a server that returns a mount authflavor list containing an AUTH_NULL entry is actually indicating it will accept any security flavor for the export being mounted. This might be used when the server maps all security flavors into the same security mode. For example, the server treats all accessors as, say, UID 17. Essentially, AUTH_NULL is treated as a wildcard that matches the flavor the mounter requested. Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> --- fs/nfs/super.c | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 4625a4c..543cf9f 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1570,13 +1570,20 @@ static int nfs_walk_authlist(struct nfs_parsed_mount_data *args, * the first flavor in the list that it supports, on the * assumption that the best access is provided by the first * flavor." + * + * By convention we treat AUTH_NULL in the returned list as + * a wild card. The server will map our requested flavor to + * something else. */ - for (i = 0; i < args->auth_flavor_len; i++) - for (j = 0; j < server_authlist_len; j++) - if (args->auth_flavors[i] == server->auth_flavs[j]) { - args->auth_flavors[0] = server->auth_flavs[j]; + for (i = 0; i < server_authlist_len; i++) { + if (server->auth_flavs[i] == RPC_AUTH_NULL) + goto out; + for (j = 0; j < args->auth_flavor_len; j++) + if (server->auth_flavs[i] == args->auth_flavors[j]) { + args->auth_flavors[0] = server->auth_flavs[i]; goto out; } + } dfprintk(MOUNT, "NFS: server does not support requested auth flavor\n"); nfs_umount(server); -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html