On Fri, 2021-10-22 at 22:07 -0700, Jeremy Allison via samba wrote:> On Sat, Oct 23, 2021 at 12:03:18AM -0400, Eric Levy via samba wrote: > > In my earlier conversation in this group, I described my needs as > > follows: > > > > What I want is multiple users on the client accessing the same > > mount > > but with different permissions enforced for each. I want the > > permissions to reflect the permissions for the corresponding > > users > > on the NAS. > > > > It seems by now it has been made clear that it is impossible to > > achieve this result without some kind of domain server... > > Isn't that the bog-standard standalone file server case, > with user names on the client mapped into the same user > names on the server ? > > The clients can easily do multi-user mounts, both Windows > and Linux. > > I guess I don't understand exactly what you are asking > for here. > > In your scenario, where are the "users" defined ? How > does a client have multiple users logged in ? Are > these local users defined on the client ?When I inquired earlier to this group, it was explained that multiuser mounts depend on a domain server, and this explanation is also given in the documentation. I think the standard standalone case is that all files in the mount share the same owner viewed by the client, perhaps with some added support for special users such as "nobody". A mount that shows different files owned by various regular users is not supported. The reason is as you say, some mechanism is required to support a user mapping, which currently is handled only by a domain server. The immediate need that interests me personally is that the same set of users are defined in the client and file server, with association occurring by equivalence of names, that is, symbolic user identifiers. The proposed class (3) is much more general, deliberately so, as its definition is to include all cases not in the other two classes. What support might be available for various cases in an actual design is obviously too detailed to discuss in this conversation. The purpose of this conversation is to explain my view that the cases currently supported are limiting, according to my understanding and in my view of what is useful to me personally and presumably also more generally for many others in a very small but still multiuser environment.
On 23/10/2021 06:28, Eric Levy via samba wrote:> > On Fri, 2021-10-22 at 22:07 -0700, Jeremy Allison via samba wrote: >> On Sat, Oct 23, 2021 at 12:03:18AM -0400, Eric Levy via samba wrote: >>> In my earlier conversation in this group, I described my needs as >>> follows: >>> >>> What I want is multiple users on the client accessing the same >>> mount >>> but with different permissions enforced for each. I want the >>> permissions to reflect the permissions for the corresponding >>> users >>> on the NAS. >>> >>> It seems by now it has been made clear that it is impossible to >>> achieve this result without some kind of domain server... >> >> Isn't that the bog-standard standalone file server case, >> with user names on the client mapped into the same user >> names on the server ? >> >> The clients can easily do multi-user mounts, both Windows >> and Linux. >> >> I guess I don't understand exactly what you are asking >> for here. >> >> In your scenario, where are the "users" defined ? How >> does a client have multiple users logged in ? Are >> these local users defined on the client ? > > When I inquired earlier to this group, it was explained that multiuser > mounts depend on a domain server, and this explanation is also given in > the documentation. I think the standard standalone case is that all > files in the mount share the same owner viewed by the client, perhaps > with some added support for special users such as "nobody". A mount > that shows different files owned by various regular users is not > supported. The reason is as you say, some mechanism is required to > support a user mapping, which currently is handled only by a domain > server. > > The immediate need that interests me personally is that the same set of > users are defined in the client and file server, with association > occurring by equivalence of names, that is, symbolic user identifiers. > > The proposed class (3) is much more general, deliberately so, as its > definition is to include all cases not in the other two classes. What > support might be available for various cases in an actual design is > obviously too detailed to discuss in this conversation. The purpose of > this conversation is to explain my view that the cases currently > supported are limiting, according to my understanding and in my view of > what is useful to me personally and presumably also more generally for > many others in a very small but still multiuser environment. > > >Isn't class 3 just a basic file server with no domain frills? All the users will have to exist on the file server and preferably with the same passwords as in Windows (as Windows tries the local username/password to connect to the share initially). My distro (ClearOS) does that using LDAP for the user database, but I'd be astonished if it were not easier to set it up with basic Linux users. If server and client passwords differ it may be easier to use "net use ...." to connect to the shares initially but have Windows remember the share mappings or you use Windows' Credential Manager. I would guess that this setup is also the setup in many NAS's.
On Sat, Oct 23, 2021 at 1:29 AM Eric Levy via samba <samba at lists.samba.org> wrote:> > On Fri, 2021-10-22 at 22:07 -0700, Jeremy Allison via samba wrote: > > On Sat, Oct 23, 2021 at 12:03:18AM -0400, Eric Levy via samba wrote: > > > In my earlier conversation in this group, I described my needs as > > > follows: > > > > > > What I want is multiple users on the client accessing the same > > > mount > > > but with different permissions enforced for each. I want the > > > permissions to reflect the permissions for the corresponding > > > users > > > on the NAS. > > > > > > It seems by now it has been made clear that it is impossible to > > > achieve this result without some kind of domain server... > > > > Isn't that the bog-standard standalone file server case, > > with user names on the client mapped into the same user > > names on the server ? > > > > The clients can easily do multi-user mounts, both Windows > > and Linux. > > > > I guess I don't understand exactly what you are asking > > for here. > > > > In your scenario, where are the "users" defined ? How > > does a client have multiple users logged in ? Are > > these local users defined on the client ? > > When I inquired earlier to this group, it was explained that multiuser > mounts depend on a domain server, and this explanation is also given in > the documentation. I think the standard standalone case is that all > files in the mount share the same owner viewed by the client, perhaps > with some added support for special users such as "nobody". A mount > that shows different files owned by various regular users is not > supported. The reason is as you say, some mechanism is required to > support a user mapping, which currently is handled only by a domain > server.You can definitely have multiple users on a "standalone" Linux client each mounting a file share on a "standalone" Samba file server. And the Samba server will enforce the user's permissions on the server side. As Jeremy said, this is the boring case which has been supported forever. I'm no Samba expert, but If I wade through everything you're saying, I think the key issue you have with that is that all of the files *appear* (on the client side) to be owned by the user who mounted the share. While that's a fairly superfluous limitation (as it has no impact on what files the user can actually see/access), it is a limitation that doesn't exist when you have a domain that can perform ID mapping. So perhaps what you're really after isn't a major "class 3" overhaul of samba, but perhaps the not-yet-fully-supported(?) SMBv3 UNIX extensions: https://wiki.samba.org/index.php/UNIX_Extensions Specifically the POSIX file ownership: https://wiki.samba.org/index.php/SMB3-Linux#POSIX_file_ownership The status of SMBv3 UNIX extension support in smbd and the Linux kernel client is not clear to me; perhaps someone more knowledgeable can fill-in here. Jonathon