[NFS-Ganesha-Support] Re: does ganesha deny access for unknown UIDs?

Hello Daniel, thank you. The clients do NFS v3 mounts, hence idmap is no option - as I know it's used in NFS v4 to map between uid/guid and names only? For a process to switch to a certain uid/guid in general one does not need a matching passwd entry? I see that with ACLs you get issues as they use names, and you can't do a server-side group membership lookup, and there may be more subtle issues. Anyway, I'll create the needed accounts on the server. By the way: We had the same issue with Netapp filers and it took a while to find the configuration option to allow 'unknown' uid/gid to access a nfs v3 export. I'll try to reproduce on a test system with increased logging to see what exactly goes wrong and maybe ask later to add a configuration option to ganesha to switch to a behaviour more similar to kernel-nfs. Many client systems at my site are legacy and run various operating systems, hence a complete switch to NFS v4 is unlikely to happen soon. cheers, Heiner -- Paul Scherrer Institut Heiner Billich System Engineer Scientific Computing Science IT / High Performance Computing WHGA/106 Forschungsstrasse 111 5232 Villigen PSI Switzerland Phone +41 56 310 36 02 heiner.billich(a)psi.ch https://www.psi.ch On 24/01/19 16:35, "Daniel Gryniewicz" <dang(a)redhat.com&gt; wrote: Hi. For local operating FSALs (like GPFS and VFS), the way Ganesha makes sure that a UID/GID combo has the correct permissions for an operation is to set the UID/GID of the thread to the one in the operation, then perform the actual operation. This way, the kernel and the underlying filesystem perform atomic permission checking on the op. This setuid/setgid will fail, of course, if the local system doesn't have that UID/GID to set to. The solution for this is to use NFS idmap to map the remote ID to a local one. This includes the ability to map unknown IDs to some local ID. Daniel On 1/24/19 9:29 AM, Billich Heinrich Rainer (PSI) wrote: