Here is the scenario:
AD-authentication is functioning fine. I can query users and group info
from wbinfo and getent just fine.
The clients can map to the shares, but cannot write to the shares. I have
tried variations of chmod 777 on absolute paths to enable read/write access
to no avail.
The share is configured as such:
[student]
comment = Test share
path = /home/share/students
public = yes
writeable = yes
browseable = yes
create mask = 0770
force create mode = 0770
directory mask = 02770
force directory mode = 02770
directory security mask = 0775
admin users = DOMAIN\Administrator
valid users = @"students"
write list = @"students"
inherit permissions = yes
inherit acls = yes
The error log reports:
[2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory)
open_directory: unable to create New folder. Error was
NT_STATUS_ACCESS_DENIED
[2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory)
open_directory: unable to create New folder. Error was
NT_STATUS_ACCESS_DENIED
[2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory)
open_directory: unable to create New folder. Error was
NT_STATUS_ACCESS_DENIED
[2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory)
open_directory: unable to create New folder. Error was
NT_STATUS_ACCESS_DENIED
[2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory)
open_directory: unable to create New folder. Error was
NT_STATUS_ACCESS_DENIED
Mike
Did you try temporarily commenting out the "valid users" and "write list" lines. That should make it writable by default. If you are then able to write it suggests that samba is not correctly matching up the users' groups to the "valid users" and "write list" groups. Although if this were the case then you would probably have been denied write permissions. Is /home/share/students an NFS/autofs mount? What happens if you create a subdirectory (via unix) under students, with group owner students, permissions 777. Can users create files under that? If you look at the advanced permissions of the directories or files in windows, do you see any "deny" ACE's that may be trumping the allow ACE's? In unix, 770 means "user and group has full access, and no one else has rights unless they are the user or group. However in Windows this may be getting interpreted as "deny everyone some rights even if they are explicited granted rights as the user or group." ( I ran into this with Samba 3.0.x with Solaris 10 and ZFS ACL's.) On 06/30/2010 09:21 AM, Michael Lyon wrote:> Here is the scenario: > > AD-authentication is functioning fine. I can query users and group info > from wbinfo and getent just fine. > > The clients can map to the shares, but cannot write to the shares. I have > tried variations of chmod 777 on absolute paths to enable read/write access > to no avail. > > The share is configured as such: > > [student] > comment = Test share > path = /home/share/students > public = yes > writeable = yes > browseable = yes > create mask = 0770 > force create mode = 0770 > directory mask = 02770 > force directory mode = 02770 > directory security mask = 0775 > admin users = DOMAIN\Administrator > valid users = @"students" > write list = @"students" > inherit permissions = yes > inherit acls = yes > > The error log reports: > [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) > open_directory: unable to create New folder. Error was > NT_STATUS_ACCESS_DENIED > [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) > open_directory: unable to create New folder. Error was > NT_STATUS_ACCESS_DENIED > [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) > open_directory: unable to create New folder. Error was > NT_STATUS_ACCESS_DENIED > [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) > open_directory: unable to create New folder. Error was > NT_STATUS_ACCESS_DENIED > [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) > open_directory: unable to create New folder. Error was > NT_STATUS_ACCESS_DENIED > > Mike >
> > > [root at vm-stusrv students]# ls -latrh > total 20K > drwxrwxrwx+ 3 root domain users 4.0K 2010-06-28 14:58 .. > drwxrwxrwx. 2 root students 4.0K 2010-06-30 09:11 test > drwxrwxrwx+ 3 root domain users 4.0K 2010-06-30 09:11 .The + sign is an ACL. getfacl <directory> Let's see what that has to say.> > > > I still cannot create files under the 'test' directory I created. > > Windows is reporting for the share that the owner and groups have > 'Special' > permissions. Drilling down into their 'special' permissions reveals > that > both 'domain users' and 'students' do have Create Folders/Write data > checked > under the 'Allow' column. (I'll attach the picture.) > > > Mike > > > On Wed, Jun 30, 2010 at 8:46 AM, Gaiseric Vandal > <gaiseric.vandal at gmail.com>wrote: > >> >> Did you try temporarily commenting out the "valid users" and "write >> list" >> lines. That should make it writable by default. If you are then >> able to >> write it suggests that samba is not correctly matching up the users' >> groups >> to the "valid users" and "write list" groups. Although if this were >> the >> case then you would probably have been denied write permissions. >> >> >> Is /home/share/students an NFS/autofs mount? What happens if you >> create a >> subdirectory (via unix) under students, with group owner students, >> permissions 777. Can users create files under that? If you >> look at >> the advanced permissions of the directories or files in windows, do >> you see >> any "deny" ACE's that may be trumping the allow ACE's? In unix, 770 >> means >> "user and group has full access, and no one else has rights unless >> they are >> the user or group. However in Windows this may be getting interpreted >> as >> "deny everyone some rights even if they are explicited granted rights >> as the >> user or group." ( I ran into this with Samba 3.0.x with Solaris 10 >> and ZFS >> ACL's.) >> >> >> >> >> >> >> >> >> >> On 06/30/2010 09:21 AM, Michael Lyon wrote: >> >>> >>> Here is the scenario: >>> >>> AD-authentication is functioning fine. I can query users and group >>> info >>> from wbinfo and getent just fine. >>> >>> The clients can map to the shares, but cannot write to the shares. I >>> have >>> tried variations of chmod 777 on absolute paths to enable read/write >>> access >>> to no avail. >>> >>> The share is configured as such: >>> >>> [student] >>> comment = Test share >>> path = /home/share/students >>> public = yes >>> writeable = yes >>> browseable = yes >>> create mask = 0770 >>> force create mode = 0770 >>> directory mask = 02770 >>> force directory mode = 02770 >>> directory security mask = 0775 >>> admin users = DOMAIN\Administrator >>> valid users = @"students" >>> write list = @"students" >>> inherit permissions = yes >>> inherit acls = yes >>> >>> The error log reports: >>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>> open_directory: unable to create New folder. Error was >>> NT_STATUS_ACCESS_DENIED >>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>> open_directory: unable to create New folder. Error was >>> NT_STATUS_ACCESS_DENIED >>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>> open_directory: unable to create New folder. Error was >>> NT_STATUS_ACCESS_DENIED >>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>> open_directory: unable to create New folder. Error was >>> NT_STATUS_ACCESS_DENIED >>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>> open_directory: unable to create New folder. Error was >>> NT_STATUS_ACCESS_DENIED >>> >>> Mike >>> >>> >> >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba >> >
> > > > [root at vm-stusrv students]# getfacl /home/share/students/ > getfacl: Removing leading '/' from absolute path names > # file: home/share/students/ > # owner: root > # group: domain\040users > user::rwx > group::rwx > group:students:rwx > mask::rwx > other::rwxGotta run, but looks ok. However, I do hate having root as an owner of user files and such. It's an unusual problem. For shts and giggles try: chown -R <Windows-User(I like group supervisors)>:<Windows Group> /home/share/students> > > Mike > > > > On Wed, Jun 30, 2010 at 9:20 AM, <tms3 at tms3.com> wrote: >> >> >> >> >> >> >> >>> >>> >>> [root at vm-stusrv students]# ls -latrh >>> total 20K >>> drwxrwxrwx+ 3 root domain users 4.0K 2010-06-28 14:58 .. >>> drwxrwxrwx. 2 root students 4.0K 2010-06-30 09:11 test >>> drwxrwxrwx+ 3 root domain users 4.0K 2010-06-30 09:11 . >> >> The + sign is an ACL. >> >> getfacl <directory> >> >> Let's see what that has to say. >> >> >> >>> >>> >>> >>> I still cannot create files under the 'test' directory I created. >>> >>> Windows is reporting for the share that the owner and groups have >>> 'Special' >>> permissions. Drilling down into their 'special' permissions reveals >>> that >>> both 'domain users' and 'students' do have Create Folders/Write data >>> checked >>> under the 'Allow' column. (I'll attach the picture.) >>> >>> >>> Mike >>> >>> >>> On Wed, Jun 30, 2010 at 8:46 AM, Gaiseric Vandal >>> <gaiseric.vandal at gmail.com>wrote: >>> >>>> >>>> Did you try temporarily commenting out the "valid users" and "write >>>> list" >>>> lines. That should make it writable by default. If you are then >>>> able to >>>> write it suggests that samba is not correctly matching up the users' >>>> groups >>>> to the "valid users" and "write list" groups. Although if this were >>>> the >>>> case then you would probably have been denied write permissions. >>>> >>>> >>>> Is /home/share/students an NFS/autofs mount? What happens if you >>>> create a >>>> subdirectory (via unix) under students, with group owner students, >>>> permissions 777. Can users create files under that? If you >>>> look at >>>> the advanced permissions of the directories or files in windows, do >>>> you see >>>> any "deny" ACE's that may be trumping the allow ACE's? In unix, 770 >>>> means >>>> "user and group has full access, and no one else has rights unless >>>> they are >>>> the user or group. However in Windows this may be getting interpreted >>>> as >>>> "deny everyone some rights even if they are explicited granted rights >>>> as the >>>> user or group." ( I ran into this with Samba 3.0.x with Solaris 10 >>>> and ZFS >>>> ACL's.) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 06/30/2010 09:21 AM, Michael Lyon wrote: >>>> >>>>> >>>>> Here is the scenario: >>>>> >>>>> AD-authentication is functioning fine. I can query users and group >>>>> info >>>>> from wbinfo and getent just fine. >>>>> >>>>> The clients can map to the shares, but cannot write to the shares. I >>>>> have >>>>> tried variations of chmod 777 on absolute paths to enable read/write >>>>> access >>>>> to no avail. >>>>> >>>>> The share is configured as such: >>>>> >>>>> [student] >>>>> comment = Test share >>>>> path = /home/share/students >>>>> public = yes >>>>> writeable = yes >>>>> browseable = yes >>>>> create mask = 0770 >>>>> force create mode = 0770 >>>>> directory mask = 02770 >>>>> force directory mode = 02770 >>>>> directory security mask = 0775 >>>>> admin users = DOMAIN\Administrator >>>>> valid users = @"students" >>>>> write list = @"students" >>>>> ?? inherit permissions = yes >>>>> inherit acls = yes >>>>> >>>>> The error log reports: >>>>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>>>> open_directory: unable to create New folder. Error was >>>>> NT_STATUS_ACCESS_DENIED >>>>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>>>> open_directory: unable to create New folder. Error was >>>>> NT_STATUS_ACCESS_DENIED >>>>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>>>> open_directory: unable to create New folder. Error was >>>>> NT_STATUS_ACCESS_DENIED >>>>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>>>> open_directory: unable to create New folder. Error was >>>>> NT_STATUS_ACCESS_DENIED >>>>> [2010/06/29 09:42:45, 2] smbd/open.c:2447(open_directory) >>>>> open_directory: unable to create New folder. Error was >>>>> NT_STATUS_ACCESS_DENIED >>>>> >>>>> Mike >>>>> >>>>> >>>> >>>> -- >>>> To unsubscribe from this list go to the following URL and read the >>>> instructions: https://lists.samba.org/mailman/options/samba >>>> >>> >> >