Jason Secord
2016-Sep-25 04:49 UTC
[Samba] Domain Member Server: Domain Users cannot access shares
Hi Rowland,>From the top down, I'm going to try and cover every step involved in thewiki and give you as much info as I can in the hope that we can get this issue resolved, or at least determine that there is nothing wrong with my config and that the underlying array has to be the weak point, even if none of us know why. *Step 1: Filesystem support* We need the filesystem to support "user and system xattr name spaces" and have ACL and XATTR support. Per the wiki ext4 "uses all the required options by default" so editing the entry in fstab is not required. My kernel must also have "CONFIG_EXT4_FS_SECURITY=y" and "CONFIG_EXT4_FS_POSIX_ACL=y" enabled. *The RAID array's filesystem:* /dev/md0: UUID="593d0107-cea3-42f5-a451-8b548a1df6f0" TYPE="*ext4*" *The RAID array's fstab entry:* /dev/md0 /mnt/md0 ext4 defaults 0 0 *My kernel config:* ~$ cat "/boot/config-`uname -r`" | grep CONFIG_EXT4_FS_SECURITY *CONFIG_EXT4_FS_SECURITY=y* ~$ cat "/boot/config-`uname -r`" | grep CONFIG_EXT4_FS_POSIX_ACL *CONFIG_EXT4_FS_POSIX_ACL=y* *Step 2: Test the filesystem* *Make sure the package "attr" is installed:* attr is already the newest version (1:2.4.47-2). *Test xattr support **(all commands executed on the /dev/md0 filesystem)**:* *Run the following commands as root to test xattr support:* root at phmsrv01:/mnt/md0# touch test.txt root at phmsrv01:/mnt/md0# setfattr -n user.test -v test test.txt root at phmsrv01:/mnt/md0# setfattr -n security.test -v test2 test.txt *The commands returned the correct output:* root at phmsrv01:/mnt/md0# getfattr -d test.txt # file: test.txt user.test="test" root at phmsrv01:/mnt/md0# getfattr -n security.test -d test.txt # file: test.txt security.test="test2" *Run the following commands as root to test extended ACL support:* root at phmsrv01:/mnt/md0# touch test.txt root at phmsrv01:/mnt/md0# setfacl -m g:adm:rwx test.txt *The commands returned the correct output:* root at phmsrv01:/mnt/md0# getfacl test.txt # file: test.txt # owner: root # group: root user::rw- group::r-- group:adm:rwx mask::rwx other::r-- *Step 3: Check Samba ACL Support:* smbd -b | grep HAVE_LIBACL *HAVE_LIBACL* *Step 4: As this is a Domain Member Server, check that extended ACL support exists in the smb.conf:* itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep acl_xattr vfs objects = acl_xattr itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep "map acl inherit" map acl inherit = yes itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep "store dos attributes" store dos attributes = yes itwerks at phmsrv01:~$ *Step 4: Ensure admin accounts have SeDiskOperatorPrivilege assigned:* itwerks at phmsrv01:~$ net rpc rights list accounts -U'PHM\administrator' -I phmadc01.phm.plymouthhistory.org PHM\Administrator SeDiskOperatorPrivilege PHM\itwerks SeDiskOperatorPrivilege PHM\Domain Admins SeDiskOperatorPrivilege Since I've already gone through the process of creating directories and we know that Domain Admins have Full Control I'm skipping those steps from the wiki. Step 5: Create a Share: I added the "Accounts" directory to my smb.conf again: [RAID-Accounts] comment = PHM Accounts Directory on RAID ARRAY path = /mnt/md0/samba_shares/Accounts read only = no and the executed *sudo smbcontrol all reload-config* *Step 6: Setup share permissions:* I logged in to a Windows 7 workstation that is joined to the domain as user "itwerks", a member of the Domain Admins group with the SeDiskOperatorPrivilege set. I opened the Computer Management snap-in and connected to PHMSRV01. (NOTE: I've always experienced this, and it hasn't ever seemed to cause any harm so I've ignored it, but the first time I expand the "System Tools" tree, or any tree for that matter, when connected to a Samba machine using this snap-in, I receive an error that the RPC service is unavailable. After clearing the notification the snap-in proceeds to connect to the Samba machine and I am able to proceed without issue. I have no idea why this happens. I viewed the shares on PHMSRV01, right-clicked "RAID-Accounts", chose "Properties" and set Share Permissions. "Everyone" is visible already and has Full Control (I have left that setting untouched). I generally require only a couple individual users to be able to access a given share, and in a few exceptions all Domain Users are authorized to do so, but in this case for testing I have added "testuser" and given them Full Control. I then saved the changes by clicking OK. *Step 7: Set ACLs on the root of a share:* I opened the "RAID-Accounts" Properties again, chose the "Security" tab, and added "testuser" with Full Control. hit OK, OK again to save changes. I am fairly certain I executed the aforementioned steps properly, and that I followed the wiki meticulously while doing so. If I am mistaken please do let me know where I went astray. *TESTING 123:* getfacl shows the updated ACLs and 'testuser' has rwx permissions for the share. itwerks at phmsrv01:~$ sudo getfacl /mnt/md0/samba_shares/Accounts [sudo] password for itwerks: getfacl: Removing leading '/' from absolute path names # file: mnt/md0/samba_shares/Accounts # owner: itwerks # group: domain\040admins user::rwx user:itwerks:rwx user:testuser:rwx group::rwx group:domain\040admins:rwx mask::rwx other::rwx default:user::rwx default:user:itwerks:rwx default:user:testuser:rwx default:group::rwx default:group:domain\040admins:rwx default:mask::rwx default:other::rwx So, time to test from another workstation as 'testuser'... I logged in to another workstation as 'testuser', a member of the Domain Users group. In Windows Explorer I navigated to \\PHMSRV01 and all shares are visible. I double-click "RAID_Accounts", the share I've been working with above, and receive the following error: *Windows cannot access \\phmsrv01\RAID-Accounts* *You do not have permission to access \\phmsrv01\RAID-Accounts. Please contact your network administrator blah blah blah.* If I copy this directory from the RAID array to the system drive, change the path in my smb.conf, and reload samba it will immediately be accessible. Unless there's something obvious I'm overlooking, which I readily admit is entirely possible, or there's some hidden nuance only a true greybeard would immediately recognise, I'm at a complete loss as to what is causing this behaviour. Please advise. Kind and Gracious Regards, JS On Fri, Sep 23, 2016 at 4:03 AM, Rowland Penny via samba < samba at lists.samba.org> wrote:> On Fri, 23 Sep 2016 03:30:10 -0400 > Jason Secord via samba <samba at lists.samba.org> wrote: > > > Mediawiki is throwing an error at this moment but I followed that > > page when I set up the shares and triple checked everything when I > > last reset ACLs. > > > > JS > > I have asked somebody to look into the wiki problem, wait until it > comes back again and then have another look. > The problem from my perpective is that I don't fully understand just > who is supposed to have access to the share. At the moment, only > 'itwerks' and 'Domain Admins' are shown by getfacl, I would expect some > other user or group to be mentioned. > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
Rowland Penny
2016-Sep-25 08:50 UTC
[Samba] Domain Member Server: Domain Users cannot access shares
On Sun, 25 Sep 2016 00:49:25 -0400 Jason Secord via samba <samba at lists.samba.org> wrote:> Hi Rowland, > > From the top down, I'm going to try and cover every step involved in > the wiki and give you as much info as I can in the hope that we can > get this issue resolved, or at least determine that there is nothing > wrong with my config and that the underlying array has to be the weak > point, even if none of us know why. > > *Step 1: Filesystem support* > > We need the filesystem to support "user and system xattr name spaces" > and have ACL and XATTR support. Per the wiki ext4 "uses all the > required options by default" so editing the entry in fstab is not > required. My kernel must also have "CONFIG_EXT4_FS_SECURITY=y" and > "CONFIG_EXT4_FS_POSIX_ACL=y" enabled. > > *The RAID array's filesystem:* > /dev/md0: UUID="593d0107-cea3-42f5-a451-8b548a1df6f0" TYPE="*ext4*" > > *The RAID array's fstab entry:* > /dev/md0 /mnt/md0 ext4 defaults 0 0 > > *My kernel config:* > ~$ cat "/boot/config-`uname -r`" | grep CONFIG_EXT4_FS_SECURITY > *CONFIG_EXT4_FS_SECURITY=y* > ~$ cat "/boot/config-`uname -r`" | grep CONFIG_EXT4_FS_POSIX_ACL > *CONFIG_EXT4_FS_POSIX_ACL=y* > > *Step 2: Test the filesystem* > > *Make sure the package "attr" is installed:* > attr is already the newest version (1:2.4.47-2). > > *Test xattr support **(all commands executed on the /dev/md0 > filesystem)**:* > > *Run the following commands as root to test xattr support:* > > root at phmsrv01:/mnt/md0# touch test.txt > root at phmsrv01:/mnt/md0# setfattr -n user.test -v test test.txt > root at phmsrv01:/mnt/md0# setfattr -n security.test -v test2 test.txt > > *The commands returned the correct output:* > > root at phmsrv01:/mnt/md0# getfattr -d test.txt > # file: test.txt > user.test="test" > > root at phmsrv01:/mnt/md0# getfattr -n security.test -d test.txt > # file: test.txt > security.test="test2" > > *Run the following commands as root to test extended ACL support:* > > root at phmsrv01:/mnt/md0# touch test.txt > root at phmsrv01:/mnt/md0# setfacl -m g:adm:rwx test.txt > > *The commands returned the correct output:* > > root at phmsrv01:/mnt/md0# getfacl test.txt > # file: test.txt > # owner: root > # group: root > user::rw- > group::r-- > group:adm:rwx > mask::rwx > other::r-- > > > *Step 3: Check Samba ACL Support:* > > smbd -b | grep HAVE_LIBACL > *HAVE_LIBACL* > > *Step 4: As this is a Domain Member Server, check that extended ACL > support exists in the smb.conf:* > > itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep acl_xattr > vfs objects = acl_xattr > itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep "map acl inherit" > map acl inherit = yes > itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep "store dos > attributes" store dos attributes = yes > itwerks at phmsrv01:~$ > > *Step 4: Ensure admin accounts have SeDiskOperatorPrivilege assigned:* > > itwerks at phmsrv01:~$ net rpc rights list accounts > -U'PHM\administrator' -I phmadc01.phm.plymouthhistory.org > > PHM\Administrator > SeDiskOperatorPrivilege > > PHM\itwerks > SeDiskOperatorPrivilege > > PHM\Domain Admins > SeDiskOperatorPrivilege > > > > Since I've already gone through the process of creating directories > and we know that Domain Admins have Full Control I'm skipping those > steps from the wiki. > > Step 5: Create a Share: > > I added the "Accounts" directory to my smb.conf again: > > [RAID-Accounts] > comment = PHM Accounts Directory on RAID ARRAY > path = /mnt/md0/samba_shares/Accounts > read only = no > > and the executed *sudo smbcontrol all reload-config* > > *Step 6: Setup share permissions:* > > I logged in to a Windows 7 workstation that is joined to the domain > as user "itwerks", a member of the Domain Admins group with the > SeDiskOperatorPrivilege set. I opened the Computer Management > snap-in and connected to PHMSRV01. > > (NOTE: I've always experienced this, and it hasn't ever seemed to > cause any harm so I've ignored it, but the first time I expand the > "System Tools" tree, or any tree for that matter, when connected to a > Samba machine using this snap-in, I receive an error that the RPC > service is unavailable. After clearing the notification the snap-in > proceeds to connect to the Samba machine and I am able to proceed > without issue. I have no idea why this happens. > > I viewed the shares on PHMSRV01, right-clicked "RAID-Accounts", chose > "Properties" and set Share Permissions. "Everyone" is visible > already and has Full Control (I have left that setting untouched). I > generally require only a couple individual users to be able to access > a given share, and in a few exceptions all Domain Users are > authorized to do so, but in this case for testing I have added > "testuser" and given them Full Control. I then saved the changes by > clicking OK. > > *Step 7: Set ACLs on the root of a share:* > > I opened the "RAID-Accounts" Properties again, chose the "Security" > tab, and added "testuser" with Full Control. hit OK, OK again to > save changes. > > > I am fairly certain I executed the aforementioned steps properly, and > that I followed the wiki meticulously while doing so. If I am > mistaken please do let me know where I went astray. > > *TESTING 123:* > > getfacl shows the updated ACLs and 'testuser' has rwx permissions for > the share. > > itwerks at phmsrv01:~$ sudo getfacl /mnt/md0/samba_shares/Accounts > [sudo] password for itwerks: > getfacl: Removing leading '/' from absolute path names > # file: mnt/md0/samba_shares/Accounts > # owner: itwerks > # group: domain\040admins > user::rwx > user:itwerks:rwx > user:testuser:rwx > group::rwx > group:domain\040admins:rwx > mask::rwx > other::rwx > default:user::rwx > default:user:itwerks:rwx > default:user:testuser:rwx > default:group::rwx > default:group:domain\040admins:rwx > default:mask::rwx > default:other::rwx > > So, time to test from another workstation as 'testuser'... > > I logged in to another workstation as 'testuser', a member of the > Domain Users group. In Windows Explorer I navigated to \\PHMSRV01 > and all shares are visible. I double-click "RAID_Accounts", the > share I've been working with above, and receive the following error: > > *Windows cannot access \\phmsrv01\RAID-Accounts* > > *You do not have permission to access \\phmsrv01\RAID-Accounts. > Please contact your network administrator blah blah blah.* > > If I copy this directory from the RAID array to the system drive, > change the path in my smb.conf, and reload samba it will immediately > be accessible. > > Unless there's something obvious I'm overlooking, which I readily > admit is entirely possible, or there's some hidden nuance only a true > greybeard would immediately recognise, I'm at a complete loss as to > what is causing this behaviour. > > Please advise. > > Kind and Gracious Regards, > > JS >This is very strange, getfacl is now showing testuser with rwx permissions, so the user should be able to connect to the share. I have been doing some work with ZFS and this has the facility to pass ACLs through the RAID to the underlying filesystem, I wonder if you need something similar ? Rowland
Jason Secord
2016-Sep-25 12:17 UTC
[Samba] Domain Member Server: Domain Users cannot access shares
Re: zfs... The odd thing is... It's not mdadm that's acting up, at least not in my opinion, as I have had two other domain member servers at other locations that host shares on filesystems that are raid arrays built with mdadm. The only difference between those boxes and this one is the LSI MegaRaid controller. Now I'm no expert when it comes to this controller, the box shipped with all the drives attached to it... And I did have a heck of a time figuring out how to get Ubuntu on the thing... These drives that make the array aren't even configured in its firmware. I'm really surprised by this problem and struggling to understand what is causing it. At this point I feel like I've got two options, either pull all the data off of them, zero them out and configure them as a new array within the controller itself, and then test it all again... Or punt and try and get LSI on the phone to explain this wizardry. I'm baffled... But at least you've confirmed my config is correct. JS On Sep 25, 2016 4:55 AM, "Rowland Penny via samba" <samba at lists.samba.org> wrote:> On Sun, 25 Sep 2016 00:49:25 -0400 > Jason Secord via samba <samba at lists.samba.org> wrote: > > > Hi Rowland, > > > > From the top down, I'm going to try and cover every step involved in > > the wiki and give you as much info as I can in the hope that we can > > get this issue resolved, or at least determine that there is nothing > > wrong with my config and that the underlying array has to be the weak > > point, even if none of us know why. > > > > *Step 1: Filesystem support* > > > > We need the filesystem to support "user and system xattr name spaces" > > and have ACL and XATTR support. Per the wiki ext4 "uses all the > > required options by default" so editing the entry in fstab is not > > required. My kernel must also have "CONFIG_EXT4_FS_SECURITY=y" and > > "CONFIG_EXT4_FS_POSIX_ACL=y" enabled. > > > > *The RAID array's filesystem:* > > /dev/md0: UUID="593d0107-cea3-42f5-a451-8b548a1df6f0" TYPE="*ext4*" > > > > *The RAID array's fstab entry:* > > /dev/md0 /mnt/md0 ext4 defaults 0 0 > > > > *My kernel config:* > > ~$ cat "/boot/config-`uname -r`" | grep CONFIG_EXT4_FS_SECURITY > > *CONFIG_EXT4_FS_SECURITY=y* > > ~$ cat "/boot/config-`uname -r`" | grep CONFIG_EXT4_FS_POSIX_ACL > > *CONFIG_EXT4_FS_POSIX_ACL=y* > > > > *Step 2: Test the filesystem* > > > > *Make sure the package "attr" is installed:* > > attr is already the newest version (1:2.4.47-2). > > > > *Test xattr support **(all commands executed on the /dev/md0 > > filesystem)**:* > > > > *Run the following commands as root to test xattr support:* > > > > root at phmsrv01:/mnt/md0# touch test.txt > > root at phmsrv01:/mnt/md0# setfattr -n user.test -v test test.txt > > root at phmsrv01:/mnt/md0# setfattr -n security.test -v test2 test.txt > > > > *The commands returned the correct output:* > > > > root at phmsrv01:/mnt/md0# getfattr -d test.txt > > # file: test.txt > > user.test="test" > > > > root at phmsrv01:/mnt/md0# getfattr -n security.test -d test.txt > > # file: test.txt > > security.test="test2" > > > > *Run the following commands as root to test extended ACL support:* > > > > root at phmsrv01:/mnt/md0# touch test.txt > > root at phmsrv01:/mnt/md0# setfacl -m g:adm:rwx test.txt > > > > *The commands returned the correct output:* > > > > root at phmsrv01:/mnt/md0# getfacl test.txt > > # file: test.txt > > # owner: root > > # group: root > > user::rw- > > group::r-- > > group:adm:rwx > > mask::rwx > > other::r-- > > > > > > *Step 3: Check Samba ACL Support:* > > > > smbd -b | grep HAVE_LIBACL > > *HAVE_LIBACL* > > > > *Step 4: As this is a Domain Member Server, check that extended ACL > > support exists in the smb.conf:* > > > > itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep acl_xattr > > vfs objects = acl_xattr > > itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep "map acl inherit" > > map acl inherit = yes > > itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep "store dos > > attributes" store dos attributes = yes > > itwerks at phmsrv01:~$ > > > > *Step 4: Ensure admin accounts have SeDiskOperatorPrivilege assigned:* > > > > itwerks at phmsrv01:~$ net rpc rights list accounts > > -U'PHM\administrator' -I phmadc01.phm.plymouthhistory.org > > > > PHM\Administrator > > SeDiskOperatorPrivilege > > > > PHM\itwerks > > SeDiskOperatorPrivilege > > > > PHM\Domain Admins > > SeDiskOperatorPrivilege > > > > > > > > Since I've already gone through the process of creating directories > > and we know that Domain Admins have Full Control I'm skipping those > > steps from the wiki. > > > > Step 5: Create a Share: > > > > I added the "Accounts" directory to my smb.conf again: > > > > [RAID-Accounts] > > comment = PHM Accounts Directory on RAID ARRAY > > path = /mnt/md0/samba_shares/Accounts > > read only = no > > > > and the executed *sudo smbcontrol all reload-config* > > > > *Step 6: Setup share permissions:* > > > > I logged in to a Windows 7 workstation that is joined to the domain > > as user "itwerks", a member of the Domain Admins group with the > > SeDiskOperatorPrivilege set. I opened the Computer Management > > snap-in and connected to PHMSRV01. > > > > (NOTE: I've always experienced this, and it hasn't ever seemed to > > cause any harm so I've ignored it, but the first time I expand the > > "System Tools" tree, or any tree for that matter, when connected to a > > Samba machine using this snap-in, I receive an error that the RPC > > service is unavailable. After clearing the notification the snap-in > > proceeds to connect to the Samba machine and I am able to proceed > > without issue. I have no idea why this happens. > > > > I viewed the shares on PHMSRV01, right-clicked "RAID-Accounts", chose > > "Properties" and set Share Permissions. "Everyone" is visible > > already and has Full Control (I have left that setting untouched). I > > generally require only a couple individual users to be able to access > > a given share, and in a few exceptions all Domain Users are > > authorized to do so, but in this case for testing I have added > > "testuser" and given them Full Control. I then saved the changes by > > clicking OK. > > > > *Step 7: Set ACLs on the root of a share:* > > > > I opened the "RAID-Accounts" Properties again, chose the "Security" > > tab, and added "testuser" with Full Control. hit OK, OK again to > > save changes. > > > > > > I am fairly certain I executed the aforementioned steps properly, and > > that I followed the wiki meticulously while doing so. If I am > > mistaken please do let me know where I went astray. > > > > *TESTING 123:* > > > > getfacl shows the updated ACLs and 'testuser' has rwx permissions for > > the share. > > > > itwerks at phmsrv01:~$ sudo getfacl /mnt/md0/samba_shares/Accounts > > [sudo] password for itwerks: > > getfacl: Removing leading '/' from absolute path names > > # file: mnt/md0/samba_shares/Accounts > > # owner: itwerks > > # group: domain\040admins > > user::rwx > > user:itwerks:rwx > > user:testuser:rwx > > group::rwx > > group:domain\040admins:rwx > > mask::rwx > > other::rwx > > default:user::rwx > > default:user:itwerks:rwx > > default:user:testuser:rwx > > default:group::rwx > > default:group:domain\040admins:rwx > > default:mask::rwx > > default:other::rwx > > > > So, time to test from another workstation as 'testuser'... > > > > I logged in to another workstation as 'testuser', a member of the > > Domain Users group. In Windows Explorer I navigated to \\PHMSRV01 > > and all shares are visible. I double-click "RAID_Accounts", the > > share I've been working with above, and receive the following error: > > > > *Windows cannot access \\phmsrv01\RAID-Accounts* > > > > *You do not have permission to access \\phmsrv01\RAID-Accounts. > > Please contact your network administrator blah blah blah.* > > > > If I copy this directory from the RAID array to the system drive, > > change the path in my smb.conf, and reload samba it will immediately > > be accessible. > > > > Unless there's something obvious I'm overlooking, which I readily > > admit is entirely possible, or there's some hidden nuance only a true > > greybeard would immediately recognise, I'm at a complete loss as to > > what is causing this behaviour. > > > > Please advise. > > > > Kind and Gracious Regards, > > > > JS > > > > This is very strange, getfacl is now showing testuser with rwx > permissions, so the user should be able to connect to the share. > > I have been doing some work with ZFS and this has the facility to pass > ACLs through the RAID to the underlying filesystem, I wonder if you > need something similar ? > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
Achim Gottinger
2016-Sep-25 13:00 UTC
[Samba] Domain Member Server: Domain Users cannot access shares
Does the user have the x right for all the folders below your share path? /mnt /mnt/md0 /mnt/md0/samba_shares Am 25.09.2016 um 06:49 schrieb Jason Secord via samba:> Hi Rowland, > > From the top down, I'm going to try and cover every step involved in the > wiki and give you as much info as I can in the hope that we can get this > issue resolved, or at least determine that there is nothing wrong with my > config and that the underlying array has to be the weak point, even if none > of us know why. > > *Step 1: Filesystem support* > > We need the filesystem to support "user and system xattr name spaces" and > have ACL and XATTR support. Per the wiki ext4 "uses all the required > options by default" so editing the entry in fstab is not required. My > kernel must also have "CONFIG_EXT4_FS_SECURITY=y" and > "CONFIG_EXT4_FS_POSIX_ACL=y" enabled. > > *The RAID array's filesystem:* > /dev/md0: UUID="593d0107-cea3-42f5-a451-8b548a1df6f0" TYPE="*ext4*" > > *The RAID array's fstab entry:* > /dev/md0 /mnt/md0 ext4 defaults 0 0 > > *My kernel config:* > ~$ cat "/boot/config-`uname -r`" | grep CONFIG_EXT4_FS_SECURITY > *CONFIG_EXT4_FS_SECURITY=y* > ~$ cat "/boot/config-`uname -r`" | grep CONFIG_EXT4_FS_POSIX_ACL > *CONFIG_EXT4_FS_POSIX_ACL=y* > > *Step 2: Test the filesystem* > > *Make sure the package "attr" is installed:* > attr is already the newest version (1:2.4.47-2). > > *Test xattr support **(all commands executed on the /dev/md0 filesystem)**:* > > *Run the following commands as root to test xattr support:* > > root at phmsrv01:/mnt/md0# touch test.txt > root at phmsrv01:/mnt/md0# setfattr -n user.test -v test test.txt > root at phmsrv01:/mnt/md0# setfattr -n security.test -v test2 test.txt > > *The commands returned the correct output:* > > root at phmsrv01:/mnt/md0# getfattr -d test.txt > # file: test.txt > user.test="test" > > root at phmsrv01:/mnt/md0# getfattr -n security.test -d test.txt > # file: test.txt > security.test="test2" > > *Run the following commands as root to test extended ACL support:* > > root at phmsrv01:/mnt/md0# touch test.txt > root at phmsrv01:/mnt/md0# setfacl -m g:adm:rwx test.txt > > *The commands returned the correct output:* > > root at phmsrv01:/mnt/md0# getfacl test.txt > # file: test.txt > # owner: root > # group: root > user::rw- > group::r-- > group:adm:rwx > mask::rwx > other::r-- > > > *Step 3: Check Samba ACL Support:* > > smbd -b | grep HAVE_LIBACL > *HAVE_LIBACL* > > *Step 4: As this is a Domain Member Server, check that extended ACL support > exists in the smb.conf:* > > itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep acl_xattr > vfs objects = acl_xattr > itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep "map acl inherit" > map acl inherit = yes > itwerks at phmsrv01:~$ cat /etc/samba/smb.conf | grep "store dos attributes" > store dos attributes = yes > itwerks at phmsrv01:~$ > > *Step 4: Ensure admin accounts have SeDiskOperatorPrivilege assigned:* > > itwerks at phmsrv01:~$ net rpc rights list accounts -U'PHM\administrator' -I > phmadc01.phm.plymouthhistory.org > > PHM\Administrator > SeDiskOperatorPrivilege > > PHM\itwerks > SeDiskOperatorPrivilege > > PHM\Domain Admins > SeDiskOperatorPrivilege > > > > Since I've already gone through the process of creating directories and we > know that Domain Admins have Full Control I'm skipping those steps from the > wiki. > > Step 5: Create a Share: > > I added the "Accounts" directory to my smb.conf again: > > [RAID-Accounts] > comment = PHM Accounts Directory on RAID ARRAY > path = /mnt/md0/samba_shares/Accounts > read only = no > > and the executed *sudo smbcontrol all reload-config* > > *Step 6: Setup share permissions:* > > I logged in to a Windows 7 workstation that is joined to the domain as user > "itwerks", a member of the Domain Admins group with the > SeDiskOperatorPrivilege set. I opened the Computer Management snap-in and > connected to PHMSRV01. > > (NOTE: I've always experienced this, and it hasn't ever seemed to cause any > harm so I've ignored it, but the first time I expand the "System Tools" > tree, or any tree for that matter, when connected to a Samba machine using > this snap-in, I receive an error that the RPC service is unavailable. > After clearing the notification the snap-in proceeds to connect to the > Samba machine and I am able to proceed without issue. I have no idea why > this happens. > > I viewed the shares on PHMSRV01, right-clicked "RAID-Accounts", chose > "Properties" and set Share Permissions. "Everyone" is visible already and > has Full Control (I have left that setting untouched). I generally require > only a couple individual users to be able to access a given share, and in a > few exceptions all Domain Users are authorized to do so, but in this case > for testing I have added "testuser" and given them Full Control. I then > saved the changes by clicking OK. > > *Step 7: Set ACLs on the root of a share:* > > I opened the "RAID-Accounts" Properties again, chose the "Security" tab, > and added "testuser" with Full Control. hit OK, OK again to save changes. > > > I am fairly certain I executed the aforementioned steps properly, and that > I followed the wiki meticulously while doing so. If I am mistaken please > do let me know where I went astray. > > *TESTING 123:* > > getfacl shows the updated ACLs and 'testuser' has rwx permissions for the > share. > > itwerks at phmsrv01:~$ sudo getfacl /mnt/md0/samba_shares/Accounts > [sudo] password for itwerks: > getfacl: Removing leading '/' from absolute path names > # file: mnt/md0/samba_shares/Accounts > # owner: itwerks > # group: domain\040admins > user::rwx > user:itwerks:rwx > user:testuser:rwx > group::rwx > group:domain\040admins:rwx > mask::rwx > other::rwx > default:user::rwx > default:user:itwerks:rwx > default:user:testuser:rwx > default:group::rwx > default:group:domain\040admins:rwx > default:mask::rwx > default:other::rwx > > So, time to test from another workstation as 'testuser'... > > I logged in to another workstation as 'testuser', a member of the Domain > Users group. In Windows Explorer I navigated to \\PHMSRV01 and all shares > are visible. I double-click "RAID_Accounts", the share I've been working > with above, and receive the following error: > > *Windows cannot access \\phmsrv01\RAID-Accounts* > > *You do not have permission to access \\phmsrv01\RAID-Accounts. Please > contact your network administrator blah blah blah.* > > If I copy this directory from the RAID array to the system drive, change > the path in my smb.conf, and reload samba it will immediately be accessible. > > Unless there's something obvious I'm overlooking, which I readily admit is > entirely possible, or there's some hidden nuance only a true greybeard > would immediately recognise, I'm at a complete loss as to what is causing > this behaviour. > > Please advise. > > Kind and Gracious Regards, > > JS > > On Fri, Sep 23, 2016 at 4:03 AM, Rowland Penny via samba < > samba at lists.samba.org> wrote: > >> On Fri, 23 Sep 2016 03:30:10 -0400 >> Jason Secord via samba <samba at lists.samba.org> wrote: >> >>> Mediawiki is throwing an error at this moment but I followed that >>> page when I set up the shares and triple checked everything when I >>> last reset ACLs. >>> >>> JS >> I have asked somebody to look into the wiki problem, wait until it >> comes back again and then have another look. >> The problem from my perpective is that I don't fully understand just >> who is supposed to have access to the share. At the moment, only >> 'itwerks' and 'Domain Admins' are shown by getfacl, I would expect some >> other user or group to be mentioned. >> >> Rowland >> >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba >>
Reasonably Related Threads
- Domain Member Server: Domain Users cannot access shares
- Domain Member Server: Domain Users cannot access shares
- Domain Member Server: Domain Users cannot access shares
- Domain Member Server: Domain Users cannot access shares
- Domain Member Server: Domain Users cannot access shares