Re: [Samba] Question concerning file permissions in Samba 3.3.4
Jeremy, Thanks for the clarification. It turns out that I had an Active Directory permission problem, and here it is: A user (We'll call him User1) was part of an Active Directory Global Group (Which I'll call Group1). Group1 is one of six Global groups which are nested in what we call Supergroup1 (also an Active Directory Global group). The issue was that we recursively assigned Full Control permissions to Supergroup1 and then assumed User1 would have Full Control on the files contained within. (At first, we thought that the reason why User1 couldn't modify those files was because Modify and Delete couldn't be selected when viewing at the file permissions in Windows Explorer. However, you set us straight on that and we now know that wasn't the problem.) The real issue is that the permissions aren't working transitively from Supergroup1 to Group1 to User1. Is there a setting that I'm missing? Note that if we assign permissions to Group1 on a directory, all is well and User1 can modify files. Thanks again for your help, Bill D. -Original Message- From: Jeremy Allison [mailto:j...@samba.org] Sent: Monday, August 17, 2009 5:26 PM To: Dorrian, William M Contractor ace...@saj Cc: samba@lists.samba.org Subject: Re: [Samba] Question concerning file permissions in Samba 3.3.4 On Mon, Aug 17, 2009 at 03:15:59PM -0400, Dorrian, William M Contractor ace...@saj wrote: We're running Samba 3.3.4 on RHEL 5 Linux, using Active Directory authentication. I've noticed that we are able to assign NTFS Full Control permissions to directories; however, we are unable to do the same on the files contained within those directories. Is there a default setting that is preventing us from being able to assign them? Note that this happens even at the very top of the directory tree... Ok, here is the deal. With Samba 3.3.x, we moved to using the returned Windows permissions (as mapped from POSIX ACLs) to control all file access. This gets us closer to Windows behavior, but there's one catch. Full Control includes the ability to delete a file, but in POSIX the ability to delete a file belongs to the containing directory, not the file itself. So when we return the Windows permissions for a file ACL with rwx set, by default we'd like to map to Full Control (see the default setting of the parameter acl map full control) but we must remove the DELETE_ACCESS flag from the mapping, as that is not a permission that is granted. Thus the ACL editor doesn't see DELETE_ACCESS in the returned ACE entry, and so doesn't believe it's Full Control. If we don't remove the DELETE_ACCESS bit, the client will open a file for delete, and successfully get a file handle back, but the delete will fail when the set file info (delete this file) call is made. Windows clients only check the error return on the open for delete call, not the actual set file info that allows the delete - if you fail that call Windows explorer silently ignores the error, tells you you have deleted the file, but the file is still there and will reappear on the next directory refresh, thus confusing users. Hopefully this explains why we can't map completely into Full Control but must remove the DELETE_ACCESS bit. It may confuse users a bit, but that's better than confusing them when they're wondering why files they've deleted keep coming back from the dead (trust me, people complained more about that for a *long* time until I discovered this work-around). Jeremy -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Question concerning file permissions in Samba 3.3.4
We're running Samba 3.3.4 on RHEL 5 Linux, using Active Directory authentication. I've noticed that we are able to assign NTFS Full Control permissions to directories; however, we are unable to do the same on the files contained within those directories. Is there a default setting that is preventing us from being able to assign them? Note that this happens even at the very top of the directory tree... Here is our smb.conf: [global] workgroup = WORKGROUP realm = REALM server string = storage interfaces = eth0 bind interfaces only = Yes security = ADS allow trusted domains = No password server = passwordserver username map = /usr/local/samba/lib/smbusers use kerberos keytab = Yes log file = /var/log/samba/%m.log ;server signing = auto socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 load printers = No printcap name = /etc/printcap dns proxy = No idmap alloc backend = tdb idmap backend = rid:WORKGROUP=16777216-33554431 idmap uid = 16777216-33554431 idmap gid = 16777216-33554431 template homedir = /home/%U winbind use default domain = No cups options = raw smb ports = 445 [array2] comment = Disk Array 2 path = /mnt/array2 read only = No admin users = admindude1 inherit acls = yes map acl inherit = yes [array3] comment = Disk Array 3 path = /mnt/array3 read only = No admin users = admindude1 inherit acls = yes map acl inherit = yes Thanks, Bill Dorrian Unix/Linux Systems Support (904) 232-2742 I did not get my Spaghetti-O's. I got spaghetti. I want the press to know this. - Thomas J. Grasso, executed by lethal injection on March 20, 1995 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Question concerning file permissions in Samba 3.3.4
On Mon, Aug 17, 2009 at 03:15:59PM -0400, Dorrian, William M Contractor ace...@saj wrote: We're running Samba 3.3.4 on RHEL 5 Linux, using Active Directory authentication. I've noticed that we are able to assign NTFS Full Control permissions to directories; however, we are unable to do the same on the files contained within those directories. Is there a default setting that is preventing us from being able to assign them? Note that this happens even at the very top of the directory tree... Ok, here is the deal. With Samba 3.3.x, we moved to using the returned Windows permissions (as mapped from POSIX ACLs) to control all file access. This gets us closer to Windows behavior, but there's one catch. Full Control includes the ability to delete a file, but in POSIX the ability to delete a file belongs to the containing directory, not the file itself. So when we return the Windows permissions for a file ACL with rwx set, by default we'd like to map to Full Control (see the default setting of the parameter acl map full control) but we must remove the DELETE_ACCESS flag from the mapping, as that is not a permission that is granted. Thus the ACL editor doesn't see DELETE_ACCESS in the returned ACE entry, and so doesn't believe it's Full Control. If we don't remove the DELETE_ACCESS bit, the client will open a file for delete, and successfully get a file handle back, but the delete will fail when the set file info (delete this file) call is made. Windows clients only check the error return on the open for delete call, not the actual set file info that allows the delete - if you fail that call Windows explorer silently ignores the error, tells you you have deleted the file, but the file is still there and will reappear on the next directory refresh, thus confusing users. Hopefully this explains why we can't map completely into Full Control but must remove the DELETE_ACCESS bit. It may confuse users a bit, but that's better than confusing them when they're wondering why files they've deleted keep coming back from the dead (trust me, people complained more about that for a *long* time until I discovered this work-around). Jeremy -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba