samba - Jun 2017 - 4.4.14 on solaris, using ads, can't read/write as user

On Fri, 30 Jun 2017 11:13:25 -0300
francis picabia via samba <samba at lists.samba.org> wrote:
> On Fri, Jun 30, 2017 at 10:26 AM, Rowland Penny via samba <
> samba at lists.samba.org> wrote:
> 
> >
> >
> > OK, What filesystem are you using ?
> >
> >
> On Solaris /tmp is technically swap.
> The partitions are generally set up as UFS, such as /
> which is on /dev/dsk/c1t1d0s0
> 
> # fstyp /dev/dsk/c1t1d0s0
> ufs
Try altering fstab to include 'acls' as an option, then add this to
smb.conf:

    vfs objects = acl_xattr
    map acl inherit = Yes
    store dos attributes = Yes

you will also need the solaris equivalents of the 'acl' &
'attr'
packages found on Debian.

This will get you closer to ACLs that AD expects.

Rowland

On Fri, Jun 30, 2017 at 11:32 AM, Rowland Penny via samba <
samba at lists.samba.org> wrote:
> On Fri, 30 Jun 2017 11:13:25 -0300
> francis picabia via samba <samba at lists.samba.org> wrote:
>
> > On Fri, Jun 30, 2017 at 10:26 AM, Rowland Penny via samba <
> > samba at lists.samba.org> wrote:
> >
> > >
> > >
> > > OK, What filesystem are you using ?
> > >
> > >
> > On Solaris /tmp is technically swap.
> > The partitions are generally set up as UFS, such as /
> > which is on /dev/dsk/c1t1d0s0
> >
> > # fstyp /dev/dsk/c1t1d0s0
> > ufs
>
> Try altering fstab to include 'acls' as an option, then add this to
> smb.conf:
>
>     vfs objects = acl_xattr
>     map acl inherit = Yes
>     store dos attributes = Yes
>
> you will also need the solaris equivalents of the 'acl' &
'attr'
> packages found on Debian.
>
> This will get you closer to ACLs that AD expects.
>
>
ACLs are already available to UFS, but not configured on the file to be
different than what ls -l shows.

getfacl on a sample file on Solaris confirms the permission is the same as
for ls -l view

We have a Debian system running Samba 4.1 which has nothing added
for acls - just regular ext4 - and it works OK for mapped user.

I've tried the settings you've suggested and it didn't change the
permissions of overwriting
or removing a file over samba.  If I made the file 777, then Samba user can
remove it.

Can you point to a changelog discussing how ACLs are now required to make
user mapping work?  We've never needed ACLs in over a decade of using Samba
from Solaris.

I've read there can be issues with /tmp so I switched the test to /var/tmp

One file (foo.txt) is made by the shell user, while the other
file (doo.txt) is made by the same user connected over Samba.

bash-3.2$ ls -n doo.txt
-rwxr--r--   1 3000     3004          29 Jul  4 09:51 doo.txt
bash-3.2$ ls -n foo.txt
-rw-rw----   1 61001    10            39 Jul  4 09:50 foo.txt

With -l they both seem to have the same user name.

This doesn't happen in 3.6, which is where Solaris was only 3 patches back.

The ID mapping seems to be the problem.

The share is currently set like this:

[tmp]
  path = /var/tmp
  public = no
  browseable = no
  read only = no
  force user = %U


%U is going with UID 3000  rather than 61001 we see on Samba 3.6.25 on
Solaris.