Samba4 Shares

**EDIT
Guys, this is 2016. We don't have sysadmins any more. Unless you're a hobbyist who is curious about the past, use something up to date instead. There's loads to choose from. We went Google. But there's also Amazon, iCloud and maybe IBM have something... 

Scenario
It sounds easy enough. You want a folder for a group of users where only they can read and write files, and bad luck anyone else. Remember the nightmarish smb.conf in Samba3? Remember all that force group=users, create mask=0660 and notsure=takeaguess stuff? Then going Google to get even more confused? Done that? Yes? OK then. You're in the right place. Let's start with the worst ever network diagram:

Our test Domain: CACTUS.

Of special note is the openSUSE logo, which is on an opaque layer above the computer photo, giving that oh so professional look. [Get on with it. :-Ed.]

We created a domain group called suseusers with rfc2307 attributes. Thanks to nss-ldapd, it works. Domain users steve4 and steve6 are members of suseusers. The story of how they got there is told here. If you feel so inclined, you can ldapsearch them on objectClass: posixAccount. So there.

So it's over to the Win 7 box which has the remote AD tools installed. 2 minute job.

First, we discover that the Windows admin can't create a folder for the share. He gets access denied when right clicking in the server window. After a bit of head scratching, we decide to get root to add some stuff, for example, adding:

[dropbox]
path = /home/CACTUS/dropbox
read only = No

to smb.conf might be a good idea. Duh!

Still no go on the Windows side. So root does some more work:

mkdir -m 0770 /home/CACTUS/dropbox

Still no go. So:

chown root:suseusers /home/CACTUS/dropbox

Now we can right click on he share and choose properties, but no security tab appears. So:

chmod g+s /home/CACTUS/dropbox

Finally. The security tab appears and Admin. can do something useful. It seems easy now, but just look at all those options. Jesus, give us a break. We are mere Linux mortals! It was at this moment that our AD admin reminded us about the 4096 possibilites of combining Linux' octal permissions with it's owners, sticky bits and acls. So maybe we have been here before after all. Anyway, we dig around to find the suseusers group and finally decide on this: 

Admin is finally allowed to , erm, administrate by root

The suseusers posixGroup on our newly customised Admin desktop

There were warnings about inherited permissions, are you sure you want to continue,  but we clicked yes anyway and hey, it looks as if it worked:

steve4 in the share

Can steve6 get at the same stuff in the share?

steve6 in the share. Looking good

All very promising on Windows so, hold on tight. It gets a lot faster now:

steve4 in the share on the Linux Client. Just look at all those -rw-rw---'s

Soooo close! When steve4 creates a file in the share from Linux, it gets rw r. When he creates it in Windows, it looks like rw r in a Linux listing but effectively it is rw rw. We can confirm this because steve6 can edit that same file. We can work around it on Linux because we have permission to change from group r to group rw. You can see steve4 doing just that in the last screenshot. But hey, we are perfectionists. He shouldn't need to do that.

Where do we go from here? Luckily at this stage, there is human intervention. Thelma from reception comes over to tell us that her computer, 'is doing that thing again' and adding, 'but this time it won't go away'. We figure that Samba is not taking the acls from the filesystem, but faking it in software. We ask Thelma where she thinks the acl's may be stored. 'Sharon can click save on hers, but mine is just all flickering', she replies.

Meanwhile, we reconnect the monitor lead for Thelma but still don't bother to tighten the screws. This inspires us. We just happen to do a:

setfacl -d -m g::rw /home/CACTUS/dropbox

steve4 now gets rw rw if he creates a file in the share logged onto the server, but rw r if on the client. NFS? Doubt it. In desperation, we restart rpc.idmapd at both ends. The id mappings are perfect. steve4 also gets rw r if he copies a file from his home folder to the share, but we expected that. Kerberos maybe? PAM? Pepe, the camarero from the bar? Under all circumstances, the group ownership remains intact no matter who has created the file. Even if root creates a file in the share on the server, it still belongs to the suseusers group. Same for Administrator in Windows.

Light relief
We discovered that Windows makes it easy for the Domain Administrator to deny himself access to shares. Twice we were were forced to take extra coffee breaks when both steve's has access to the files in the share, but not Admin. The clue was in the Admin screenshot above;-) Talking of administrators being refused entry to their own systems:

He he he. Note the sly grin on the gss daemon

Heavy relief
Yes, of course. Eternal optimists. samba-tool is your friend. It will help you out with this one. Next thing we know:

samba-tool ntacl get /home/CACTUS/dropbox/
file: struct xattr_NTACL
    version                  : 0x0001 (1)
    info                     : union xattr_NTACL_Info(case 1)
    sd                       : *
        sd: struct security_descriptor
            revision                 : SECURITY_DESCRIPTOR_REVISION_1 (1)
            type                     : 0x8004 (32772)
                   0: SEC_DESC_OWNER_DEFAULTED 
                   0: SEC_DESC_GROUP_DEFAULTED 
                   1: SEC_DESC_DACL_PRESENT    
                   0: SEC_DESC_DACL_DEFAULTED  
                   0: SEC_DESC_SACL_PRESENT    
                   0: SEC_DESC_SACL_DEFAULTED  
                   0: SEC_DESC_DACL_TRUSTED    
                   0: SEC_DESC_SERVER_SECURITY 
                   0: SEC_DESC_DACL_AUTO_INHERIT_REQ
                   0: SEC_DESC_SACL_AUTO_INHERIT_REQ
                   0: SEC_DESC_DACL_AUTO_INHERITED
                   0: SEC_DESC_SACL_AUTO_INHERITED
                   0: SEC_DESC_DACL_PROTECTED  
                   0: SEC_DESC_SACL_PROTECTED  
                   0: SEC_DESC_RM_CONTROL_VALID
                   1: SEC_DESC_SELF_RELATIVE   
            owner_sid                : *
                owner_sid                : S-1-5-21-443838659-2890314986-1722269781-500
            group_sid                : *
                group_sid                : S-1-22-2-0
            sacl                     : NULL
            dacl                     : *
                dacl: struct security_acl
                    revision                 : SECURITY_ACL_REVISION_NT4 (2)
                    size                     : 0x007c (124)
                    num_aces                 : 0x00000004 (4)
                    aces: ARRAY(4)
                        aces: struct security_ace
                            type                     : SEC_ACE_TYPE_ACCESS_ALLOWED (0)
                            flags                    : 0x00 (0)
                                   0: SEC_ACE_FLAG_OBJECT_INHERIT
                                   0: SEC_ACE_FLAG_CONTAINER_INHERIT
                                   0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
                                   0: SEC_ACE_FLAG_INHERIT_ONLY
                                   0: SEC_ACE_FLAG_INHERITED_ACE
                                0x00: SEC_ACE_FLAG_VALID_INHERIT (0)
                                   0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
                                   0: SEC_ACE_FLAG_FAILED_ACCESS
                            size                     : 0x0018 (24)
                            access_mask              : 0x001200a9 (1179817)
                            object                   : union security_ace_object_ctr(case 0)
                            trustee                  : S-1-22-2-0
                        aces: struct security_ace
                            type                     : SEC_ACE_TYPE_ACCESS_ALLOWED (0)
                            flags                    : 0x00 (0)
                                   0: SEC_ACE_FLAG_OBJECT_INHERIT
                                   0: SEC_ACE_FLAG_CONTAINER_INHERIT
                                   0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
                                   0: SEC_ACE_FLAG_INHERIT_ONLY
                                   0: SEC_ACE_FLAG_INHERITED_ACE
                                0x00: SEC_ACE_FLAG_VALID_INHERIT (0)
                                   0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
                                   0: SEC_ACE_FLAG_FAILED_ACCESS
                            size                     : 0x0014 (20)
                            access_mask              : 0x001f01ff (2032127)
                            object                   : union security_ace_object_ctr(case 0)
                            trustee                  : S-1-5-18
                        aces: struct security_ace
                            type                     : SEC_ACE_TYPE_ACCESS_ALLOWED (0)
                            flags                    : 0x03 (3)
                                   1: SEC_ACE_FLAG_OBJECT_INHERIT
                                   1: SEC_ACE_FLAG_CONTAINER_INHERIT
                                   0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
                                   0: SEC_ACE_FLAG_INHERIT_ONLY
                                   0: SEC_ACE_FLAG_INHERITED_ACE
                                0x03: SEC_ACE_FLAG_VALID_INHERIT (3)
                                   0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
                                   0: SEC_ACE_FLAG_FAILED_ACCESS
                            size                     : 0x0024 (36)
                            access_mask              : 0x001301bf (1245631)
                            object                   : union security_ace_object_ctr(case 0)
                            trustee                  : S-1-5-21-443838659-2890314986-1722269781-1112
                        aces: struct security_ace
                            type                     : SEC_ACE_TYPE_ACCESS_ALLOWED (0)
                            flags                    : 0x03 (3)
                                   1: SEC_ACE_FLAG_OBJECT_INHERIT
                                   1: SEC_ACE_FLAG_CONTAINER_INHERIT
                                   0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
                                   0: SEC_ACE_FLAG_INHERIT_ONLY
                                   0: SEC_ACE_FLAG_INHERITED_ACE
                                0x03: SEC_ACE_FLAG_VALID_INHERIT (3)
                                   0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
                                   0: SEC_ACE_FLAG_FAILED_ACCESS
                            size                     : 0x0024 (36)
                            access_mask              : 0x001f01ff (2032127)
                            object                   : union security_ace_object_ctr(case 0)
                            trustee                  : S-1-5-21-443838659-2890314986-1722269781-500

Now we understand. Why didn't we think of that in the first place!

The question remains. How do we get pure and simple rw rw on the dropbox share? That's all we're asking. Reward offered for evidence leading to the arrest of the missing w. Yeah, we want posix to nfs4 to nt acls. But no one is going to give us that are they within the next decade. Are they?

Conclusion
nt acls from Windows work. POSIX acl's work locally, but not over nfs4. So let's mount it and set the nfs4 acl's:

hh3:/home/CACTUS # nfs4_setfacl -a A:fdi:GROUP@:RWX /mnt/CACTUS/dropbox

hh3:/home/CACTUS # nfs4_getfacl /mnt/CACTUS/dropbox/
A::OWNER@:rwaDxtTcCy
A::GROUP@:rwaDxtcy
A::EVERYONE@:tcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:GROUP@:rwaDxtcy
A:fdi:EVERYONE@:tcy 
Still no rw:-(

Workaround
1. Use a big hammer:
#!/bin/sh
while true; do $(chmod -R 660 /home/dropbox/*); sleep 4; done

2. Tap it lightly:
#!/bin/sh
share=/home/CACTUS/dropbox/
cd $share
while true
do
 if [ -N $share ]; then
for a in *
do
listing=$(ls -l $a)
perm=$(echo $listing | cut -d "-" -f 3)
if [ $perm != "rw" ]; then
echo $(chmod g+w $a)
# echo "$a was changed"
fi
done 
fi
sleep 4
done

3. Don't use nfs4
Use nfs3 instead. nfs3 preserves POSIX acls:-)
If you have already configured nfs4, on openSUSE use Yast:

Which in old money amounts to this:
 grep -v "#" /etc/sysconfig/nfs
USE_KERNEL_NFSD_NUMBER="4"
MOUNTD_PORT=""
NFS_SECURITY_GSS="yes"
NFS3_SERVER_SUPPORT="no"
NFS4_SUPPORT="no"
SM_NOTIFY_OPTIONS=""
NFS_START_SERVICES="yes"
STATD_OPTIONS=""
NFSV4LEASETIME=""
RPC_PIPEFS_DIR=""
SVCGSSD_OPTIONS=""
NFSD_OPTIONS=""

On Ubuntu:

Seems to be OK as it is. Just change the mount command:

 mount -t nfs hh3:/home /mnt -o vers=3,sec=krb5

and mount gives:
/home on /mnt type nfs (rw,vers=3,sec=krb5,addr=192.168.1.3)

  cd /mnt/CACTUS/

lynn2@hh3:/mnt/CACTUS$ ls -la dropbox/

-rw-rw----  1 lynn2 debusers    0 2012-03-01 14:40 l4

lynn2@hh3:/mnt/CACTUS$ cd dropbox/

lynn2@hh3:/mnt/CACTUS/dropbox$ touch l5

lynn2@hh3:/mnt/CACTUS/dropbox$ ls -l l5

-rw-rw---- 1 lynn2 debusers 0 2012-03-01 14:43 l5

YEAH! The acl + is there and the file gets group rw without the rw workaround running.