On Wed, 2021-06-30 at 16:19 -0400, Eric Levy via samba
wrote:> On Thu, 2021-06-24 at 14:29 +0100, Rowland Penny via samba wrote:
> > > It might help at least if I would receive advice on the subject,
> > > putting aside the question of customization to the Samba code
> > > base.
> > > If
> > > it is possible to achieve the configuration using standard
> > > versions
> > > of
> > > Samba, then it is at least worth trying the same method with the
> > > Synology device.
> >
> > Running Samba as a standalone server is akin to running a Windows
> > PC
> > in
> > a workgroup, so this is what I would try:
> >
> > Use the same workgroup name on all machines.
> > Create the same users and groups on all machines, ensure that the
> > users
> > have the same password everywhere.
> >
> > Rowland
>
> Sorry, for not returning a reply to your suggestion earlier, but I am
> still trying to resolve this problem, and must remark that I have
> found
> your idea confusing.
>
> For a Samba mount in a basic form, all files in the mount take the
> same
> owner and permissions, generally the owner being root. The function
> of
> the multiuser option, as I understand, is to enforce different
> permissions for each user on the system. Without this option, would
> various users have different permissions for files on the mount?
>
> Perhaps you might illustrate your idea with a concrete minimal case
> showing, for example, the mount command.
Try read 'man mount.cifs'
Where you will find this:
multiuser
Map user accesses to individual credentials when
accessing the server. By default, CIFS mounts only use a single set of
user credentials (the mount credentials) when ac?
cessing a share. With this option, the client instead
creates a new session with the server using the user's credentials
whenever a new user accesses the mount. Further
accesses by that user will also use those credentials.
Because the kernel cannot prompt for passwords, multiuser mounts are
limited to mounts using sec= options that don't
require passwords.
With this change, it's feasible for the server to handle
permissions enforcement, so this option also implies noperm .
Furthermore, when unix extensions aren't in use and
the administrator has not overridden ownership using the
uid= or gid= options, ownership of files is presented as the current
user accessing the share.
Which shows that you have a problem 'multiuser mounts are limited to
mounts using sec= options that don't require passwords.' or to put it
another way, kerberos.
Rowland