Frank Filz

Access outside the export by handle spoofing is always a risk... Solution has always been to have dedicated filesystems for export. Ganesha doesn't give NFS clients access to arbitrary filesystems...

Can we close this?

Closing, no response in more than 60 days.

Does the crash only occur with USE_MONITORING?

We have considered multi-tenancy issues but have not yet committed to any specific effort. The best out of the box option I think would be running multiple Ganesha instances in...

So the pseduopath stuff I was talking about earlier: Let's say you have exports: /export/customer1/export1 /export/customer1/export2 /export/customer2/export1 /export/customer2/export2 Without doing anything and configuring 4 exports, all users will be able...

This may be happening because some other process has the file open. Ganesha should close any opens it has for files that are deleted.

What NFS versions are the clients using? Are you using FSAL_GLUSTER? Is there a single Ganesha node, or are there two? It's not quite clear what your setup is. This...

I'm not sure why having Path and Pseudo the same impact this, though you might consider NFS_CORE_PARAM { Mount_Path_Pseudo = TRUE; } that will make NFSv3 clients specify the same...

We have some patches fixing lifetime of fsal_fd: https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1176997?usp=search There is at least one merged into V6-dev.5 or earlier (soon we will backport some patches and tag V5.8)