June 2026 - Devel - Nfs Ganesha List Archives

[S] Change in ...nfs-ganesha[next]: Fix: Prevent releasing uninitialized op_context in LAYOUTRETURN

by ofir vainshtein (GerritHub)

ofir vainshtein has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238445?usp=email ) Change subject: Fix: Prevent releasing uninitialized op_context in LAYOUTRETURN ...................................................................... Fix: Prevent releasing uninitialized op_context in LAYOUTRETURN The release_op_context() call in nfs4_op_layoutreturn is now conditional on whether init_op_context_simple() was actually called. This avoids attempting to release an op_context that was never initialized. Change-Id: Idef7164578e0febd1296650d4df68ead6570f765 Signed-off-by: Ofir Vainshtein <ofirvins(a)google.com> --- M src/Protocols/NFS/nfs4_op_layoutreturn.c 1 file changed, 7 insertions(+), 4 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/45/1238445/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238445?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Idef7164578e0febd1296650d4df68ead6570f765 Gerrit-Change-Number: 1238445 Gerrit-PatchSet: 1 Gerrit-Owner: ofir vainshtein <ofirvins(a)google.com>

2 weeks, 4 days

1
0
0 / 0

[XS] Change in ...nfs-ganesha[next]: Add bounds check for NFSv4 attribute index.

by ofir vainshtein (GerritHub)

ofir vainshtein has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238444?usp=email ) Change subject: Add bounds check for NFSv4 attribute index. ...................................................................... Add bounds check for NFSv4 attribute index. In nfs4_check_attr_mask, validate that each attribute index derived from the attribute mask does not exceed FATTR4_MAX_ATTR_INDEX. Log a warning and return false if an out-of-range index is found. Change-Id: If06631d2b71efe7f3f91684d89c437077a03b869 Signed-off-by: Ofir Vainshtein <ofirvins(a)google.com> --- M src/Protocols/NFS/nfs_proto_tools.c 1 file changed, 6 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/44/1238444/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238444?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: If06631d2b71efe7f3f91684d89c437077a03b869 Gerrit-Change-Number: 1238444 Gerrit-PatchSet: 1 Gerrit-Owner: ofir vainshtein <ofirvins(a)google.com>

2 weeks, 4 days

1
0
0 / 0

[S] Change in ...nfs-ganesha[next]: Fix buffer overflow and missing null-termination in name2id

by Lior Suliman (GerritHub)

Attention is currently required from: Frank Filz. Hello Frank Filz, I'd like you to do a code review. Please visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238405?usp=email to review the following change. Change subject: Fix buffer overflow and missing null-termination in name2id ...................................................................... Fix buffer overflow and missing null-termination in name2id When idmapping is disabled, `atless2id` was called directly with `name->addr` (which is not guaranteed to be null-terminated), risking out-of-bounds reads. Fix this by copying `name->addr` to a stack- allocated, null-terminated buffer (`namebuff`) before the call. Change-Id: I944a8cc399da9b269ef11ff4319b63b8bb88f391 Signed-off-by: Lior Suliman <liorsu(a)gmail.com> --- M src/idmapper/idmapper.c M src/include/nfsv41.h 2 files changed, 8 insertions(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/05/1238405/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238405?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I944a8cc399da9b269ef11ff4319b63b8bb88f391 Gerrit-Change-Number: 1238405 Gerrit-PatchSet: 1 Gerrit-Owner: Lior Suliman <liorsu(a)google.com> Gerrit-Reviewer: Frank Filz <ffilzlnx(a)mindspring.com> Gerrit-Attention: Frank Filz <ffilzlnx(a)mindspring.com>

2 weeks, 4 days

1
0
0 / 0

[XS] Change in ...nfs-ganesha[next]: Conditionally retrieve ACLs in access check

by Name of user not set (GerritHub)

inneek(a)gmail.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238404?usp=email ) Change subject: Conditionally retrieve ACLs in access check ...................................................................... Conditionally retrieve ACLs in access check Dynamically query the ATTR_ACL attribute in fsal_test_access only if an ACL-based access check is requested. Change-Id: Ic08f9c4f5cb7d7df9ae9a76a81171da57df5d840 Signed-off-by: Inna Batenkov <inneek(a)gmail.com> --- M src/FSAL/access_check.c 1 file changed, 8 insertions(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/04/1238404/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238404?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Ic08f9c4f5cb7d7df9ae9a76a81171da57df5d840 Gerrit-Change-Number: 1238404 Gerrit-PatchSet: 1 Gerrit-Owner: inneek(a)gmail.com

2 weeks, 4 days

1
0
0 / 0

Run multiple instances of NFSv4 server on same host / proper use of NFS_CORE_PARAM NFS_Program

by Dr. Thomas Orgis

Hi, I am investigating the option of running nfs-ganesha in an unprivileged user/mount namespace on Linux, to export some directory only visible there, in addition to a main NFS server on the same host. It should be a simple world-readable share, no security considerations client-side. The machine hosts a regular NFS v3 and v4 service that should not be bothered with this task (and it cannot access the FUSE-based mount in the namespace that should be exported, and probably should not for containment/security reasons). I figured that it should be possible to run a NFSv4 server on a different TCP port than 2049, not needing further RPC port mapping. I tried this: NFS_CORE_PARAM { Protocols = 4; NFS_Port = 2050; Enable_UDP = false; Bind_addr = [some IP]; } NFS_KRB5 { Active_krb5 = false; } But soon realized that I am forced to specify additional values to make ganesha.nfsd even try to start, even if I don't need rquota, for example: NFS_CORE_PARAM { Rquota_Port = 8750; # even for nfsv4, ganesha insists on rpcbind?! NFS_Program = 200003; Rquota_Program = 200001; } I can of course not use the default NFS_Program value, as that is occupied by the main NFS instance. Well, at least I assume that from this error: 09/05/2026 18:00:53 : epoch 69ff5a35 : server : ganesha.nfsd-3213231[main] __Register_program :DISP :MAJ :Cannot register NFS V4 on TCP When I run with this setup, the client can contact ganesha, but errors out: client:/# mount -o nfsvers=4.2,proto=tcp,port=2050,ro server:/mount /mount mount.nfs: Protocol family not supported And I see this message in ganesha log with -N FULL_DEBUG: 09/05/2026 17:48:28 : epoch 69ff5747 : server : ganesha.nfsd-3207650[svc_6] nfs_rpc_noprog :DISP :F_DBG :Invalid Program number 100003 This suggests that I still do have a conflict with the RPC program 100003 … I am not that intimate with the details of the NFS protocol. The client does not need to RPC portmap, but the RPC stuff is still needed on the server and prevents multiple instances of NFS servers on one system? What is NFS_Program even for when client mount requests result in Program number 100003 being tried, anyway? Is there another trick I need to add to make this work? When I don't specify NFS_Program to a different value, the client gets mount.nfs: mounting server:/mount failed, reason given by server: No such file or directory I see 09/05/2026 18:03:48 : epoch 69ff5aaf : server : ganesha.nfsd-3214122[svc_2] nfs_rpc_process_request :DISP :DEBUG :Request from ::ffff:[client_ip] for Program 100003, Version 4, Function 1 has xid=1120240127 This seems to imply that the client hardcodes program 100003. I don't see an option for that in nfs(5). Could it be that a simple modification in mount.nfs to add an option for the RPC program to call would enable multiple instances of NFSv4 servers on one system, and that right now the presense of NFS_Program in ganesha config doesn't serve a purpose, at least with Linux kernel clients? Alrighty then, Thomas PS: I have this very setup running with Samba smbd in the namespace kistening on a non-standard port instead of NFS, wich works in principle, but the share needs to support file names with ':' in them, and POSIX semantics in general, so that I figured NFS would be the choice after all. The v9fs Linux client has some warnings to it regarding robustness that make me hesitate to switch to that protocol. -- Dr. Thomas Orgis HPC @ Universität Hamburg

2 weeks, 5 days

1
2
0 / 0

[XS] Change in ...nfs-ganesha[next]: GPFS: Fix pynfs failure for RDLK1

by Sachin Punadikar (GerritHub)

Sachin Punadikar has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238270?usp=email ) Change subject: GPFS: Fix pynfs failure for RDLK1 ...................................................................... GPFS: Fix pynfs failure for RDLK1 With new function "copy_into_utf8string", no need to consider additional one byte for string length Change-Id: I61b2b3cb862ed7075295da091554207283d9999b Signed-off-by: Sachin Punadikar <sachin.punadikar(a)ibm.com> --- M src/FSAL/FSAL_GPFS/handle.c 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/70/1238270/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238270?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I61b2b3cb862ed7075295da091554207283d9999b Gerrit-Change-Number: 1238270 Gerrit-PatchSet: 1 Gerrit-Owner: Sachin Punadikar <sachin.punadikar(a)ibm.com>

2 weeks, 6 days

1
0
0 / 0

[M] Change in ...nfs-ganesha[next]: Monitoring: New way of scraping metrics

by Name of user not set (GerritHub)

sragraha(a)redhat.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238269?usp=email ) Change subject: Monitoring: New way of scraping metrics ...................................................................... Monitoring: New way of scraping metrics Change-Id: Id8cbfa830df2d478cac051ac6be2741a105adf52 Signed-off-by: Sreedhar Agraharam <sragraha(a)redhat.com> --- M src/MainNFSD/libganesha_nfsd.ver M src/MainNFSD/nfs_metrics.c M src/MainNFSD/nfs_rpc_dispatcher_thread.c M src/include/nfs_core.h M src/include/nfs_metrics.h M src/monitoring/include/prometheus_exposer.h M src/monitoring/prometheus_exposer.cc 7 files changed, 75 insertions(+), 50 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/69/1238269/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1238269?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Id8cbfa830df2d478cac051ac6be2741a105adf52 Gerrit-Change-Number: 1238269 Gerrit-PatchSet: 1 Gerrit-Owner: sragraha(a)redhat.com

2 weeks, 6 days

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

Devel June 2026