Connecting to a share remotely with Windows XP, only allows me to create a file, but not modify or delete it afterwards. I can connect to the same share, using the same credentials, but using another solaris box and "smbclient -k", and I have the permissions I'd expect to have. Relevant information: bash-3.00# uname -a SunOS XXXXX 5.9 Generic_117171-14 sun4u sparc SUNW,Sun-Blade-100 Compiled samba 3.0.14a from source with options: --with-acl-support \ --with-included-popt \ --localstatedir=/var/lib/samba \ --with-piddir=/var/run \ --with-logfilebase=/var/log/samba \ --with-privatedir=/etc/samba/private \ --with-configdir=/etc/samba \ --with-ads \ --with-pam \ --with-pam_smbpass \ --with-winbind \ --with-quotas Share information: [Archive] path = /samba/archive valid users = @DOMAIN\planet-archive-t-m force group = samba read only = No create mask = 0660 force create mode = 0660 security mask = 00 force directory mode = 0770 directory security mask = 00 force directory security mode = 0770 preserve case = No browseable = No Global samba config: [global] dos charset = ASCII display charset = ASCII workgroup = DOMAIN realm = DOMAIN.CA server string = Samba Server interfaces = eri0, lo0 bind interfaces only = Yes security = ADS allow trusted domains = No password server = ad1.DOMAIN.ca ad3.DOMAIN.ca log file = /usr/local/samba/var/log.%m max log size = 500 load printers = No preferred master = No local master = No domain master = No idmap uid = 10000-20000 idmap gid = 10000-20000 template homedir = /export/home/%D/%U template shell = /bin/bash winbind cache time = 10 Share Directory permissions: bash-3.00# getfacl /samba/archive # file: /samba/archive # owner: root # group: other user::rwx group::rwx #effective:rwx group:SNB\planet-map-admin-m:rwx #effective:rwx mask:rwx other:r-x bash-3.00# smbstatus Samba version 3.0.14a PID Username Group Machine ------------------------------------------------------------------- 1936 SNB\xbking SNB\domain users 142.139.93.8 (142.139.93.8) 2012 SNB\xbking SNB\domain users onottnb023257 (142.139.223.238) Service pid machine Connected at ------------------------------------------------------- Archive 1936 142.139.93.8 Thu Jun 9 22:42:36 2005 Archive 2012 onottnb023257 Thu Jun 9 22:53:12 2005 No locked files bash-3.00# pcred 1936 1936: euid=10418 ruid=0 suid=10418 egid=506 rgid=0 sgid=506 groups: 10000 10001 10006 10008 10024 10027 10101 10111 10116 10137 10262 10813 10827 10828 10829 bash-3.00# pcred 2012 2012: euid=0 ruid=0 suid=10418 egid=0 rgid=0 sgid=506 Process 1936 is an 'smbclient -k' session from a remote machine, with the share, and I can create and delete files in the share. Notice how this process has all the proper groups in the 10000-20000 range associated with it. Process 10262 is a windows XP session with the share and I can create a file, but can not delete or rename it afterwards. Notice how the process does not have any of the "groups" information. I have another machine with the same configuration, but using Samba 3.0.0rc3, and it does not have this problem.
The results of 'pcred' may be a red herring. After disconnecting and reconnecting, several times with both clients, it appears that the smbclient associated smbd always has the group credentials, but the windows associated one has it at times, but not at others (no immediately discernable pattern). Whether the windows client has the groups associated with it's process or not, it still has the same problem.
A second user has tried the same experiment, and whether he uses smbclient or Windows XP client, his process never has the groups assigned, and he cannot even create files in the folder. He is a member of the same AD group I am which allows me to write to the directory (and delete if using smbclient). One difference we can see is that I have less that 16 groups in AD, and he has more than 16.
Ah - that explains your problem. Solaris will only allow 16 supplementary groups. IMHO this is a bug in Solaris. There's nothing that Samba can do to fix this, it's an inherant limitation in the OS. You might want to try a modern Linux distribution which has no limit on the supplementary groups list. It's either that or bug Sun to fix this.... Closing as it's not a Samba bug. Jeremy.
the 16 groups doesn't explain the behavior with my account being different when logging in through smbclient vs. windows XP. 16 groups was just a guess at why the behavior was different from 2 different domain accounts. With smbclient, I can create, rename, and delete files from the root of the share. With windows, I can only create new files, I cannot rename or delete. Whatever permission allowed me to create a file (group write on the directory), should allow me to rename and delete. From windows, I can create a subfolder (ends up with the same permissions as the parent), and from within the subfolder I can create, rename and delete.
If you're using an OS that only allows 16 supplementary groups you're going to find users with more groups than that get intermittent problems. As for the delete/rename problem I'd suggest you try a Samba 3.0.15 pre-release or the current SAMBA_3_0 svn source as there have been some fixes in that area to do with ACL evaluation. Jeremy.
The user experiencing the problem is only in 14 groups: bash-3.00# wbinfo -r DOMAIN\\xbking | wc -l 14 It works consistantly with smbclient, and fails consistantly with Windows client. I also retested without the facls, and using the AD group as the group permission on the file. Same results. Everything works as expected when I add world write to the directory, so it appears as if the group memberships are not being recognized when logging in from a windows client, but for some reason, only at the top level of the share.
Not sure if this helps, but here is a 'truss' of 2 sessions (smbd). Both attempting to rename x.cap to yy.cap (y.cap in the second session). The smbclient one (first one) is successfull, the windows one (second one) is unsuccessfull. You can see they both check if x.cap exists, then check if y.cap exists, then open the directory, recheck them both, then only one of them (smbclient) ever calls the 'rename'. Only the windows client calls the acl(".", GETACL, 16, 0x0039DC54) = 5 SMBclient session successfully renaming file: bash-3.00# truss -faeldp 4119 4119/1: *** SUID: ruid/euid/suid = 0 / 10000 / 10000 *** 4119/1: *** SGID: rgid/egid/sgid = 0 / 10005 / 10005 *** Base time stamp: 1118428918.3770 [ Fri Jun 10 15:41:58 ADT 2005 ] 4119/1: psargs: /opt/samba/sbin/smbd -D -s/opt/samba/lib/smb.conf 4119/1: poll(0xFFBFF7D0, 3, 60000) (sleeping...) 4119/1: 2.8933 poll(0xFFBFF7D0, 3, 60000) = 1 4119/1: 2.8938 read(26, "\0\0\0 (", 4) = 4 4119/1: 2.8944 read(26, "FF S M B10\0\0\0\0\b01C8".., 40) = 40 4119/1: 2.8947 stat64(".", 0xFFBFF3E8) = 0 4119/1: 2.8952 send(26, "\0\0\0 #FF S M B10\0\0\0".., 39, 0) = 39 4119/1: 2.8955 time() = 1118428921 4119/1: poll(0xFFBFF7D0, 3, 60000) (sleeping...) 4119/1: 6.2150 poll(0xFFBFF7D0, 3, 60000) = 1 4119/1: 6.2155 read(26, "\0\0\0 F", 4) = 4 4119/1: 6.2159 read(26, "FF S M B07\0\0\0\0\b01C8".., 70) = 70 4119/1: 6.2164 stat64("x.cap", 0xFFBFCEA0) = 0 4119/1: 6.2169 stat64("yy.cap", 0xFFBFCEA0) Err#2 ENOENT 4119/1: 6.2173 stat64("yy.cap", 0xFFBFCEA0) Err#2 ENOENT 4119/1: 6.2178 open(".", O_RDONLY|O_NDELAY|O_LARGEFILE) = 23 4119/1: 6.2182 fstat64(23, 0xFFBFBFD8) = 0 4119/1: 6.2184 fcntl(23, F_SETFD, 0x00000001) = 0 4119/1: 6.2186 getdents64(23, 0x0034C3A0, 8192) = 344 4119/1: 6.2188 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2189 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2191 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2193 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2194 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2196 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2198 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2199 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2201 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2202 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2204 llseek(23, 0, SEEK_CUR) = 512 4119/1: 6.2205 getdents64(23, 0x0034C3A0, 8192) = 0 4119/1: 6.2207 close(23) = 0 4119/1: 6.2213 stat64("./x.cap", 0xFFBFE088) = 0 4119/1: 6.2217 fcntl(13, F_SETLKW64, 0xFFBFCC50) = 0 4119/1: 6.2220 fcntl(13, F_SETLKW64, 0xFFBFC760) = 0 4119/1: 6.2223 fcntl(13, F_SETLKW64, 0xFFBFC760) = 0 4119/1: 6.2225 fcntl(13, F_SETLKW64, 0xFFBFC718) = 0 4119/1: 6.2227 fcntl(13, F_SETLKW64, 0xFFBFC718) = 0 4119/1: 6.2228 fcntl(13, F_SETLKW64, 0xFFBFCC50) = 0 4119/1: 6.2257 fcntl(13, F_SETLKW64, 0xFFBFCC40) = 0 4119/1: 6.2260 fcntl(13, F_SETLK64, 0xFFBFCA50) = 0 4119/1: 6.2263 fcntl(13, F_SETLK64, 0xFFBFCA50) = 0 4119/1: 6.2264 fcntl(13, F_SETLKW64, 0xFFBFC9C0) = 0 4119/1: 6.2266 fcntl(13, F_SETLKW64, 0xFFBFC9C0) = 0 4119/1: 6.2268 fcntl(13, F_SETLKW64, 0xFFBFC708) = 0 4119/1: 6.2270 fcntl(13, F_SETLKW64, 0xFFBFC708) = 0 4119/1: 6.2272 fcntl(13, F_SETLKW64, 0xFFBFCC40) = 0 4119/1: 6.2275 fcntl(12, F_SETLKW64, 0xFFBFCB98) = 0 4119/1: 6.2277 fcntl(12, F_SETLKW64, 0xFFBFCB98) = 0 4119/1: 6.2279 stat64("./yy.cap", 0xFFBFCEA0) Err#2 ENOENT 4119/1: 6.2289 rename("./x.cap", "./yy.cap") = 0 4119/1: 6.2295 send(26, "\0\0\0 #FF S M B07\0\0\0".., 39, 0) = 39 4119/1: 6.2298 time() = 1118428924 4119/1: poll(0xFFBFF7D0, 3, 60000) (sleeping...) Windows Session failing to rename file: bash-3.00# truss -faeldp 4033 4033/1: *** SUID: ruid/euid/suid = 0 / 10000 / 10000 *** 4033/1: *** SGID: rgid/egid/sgid = 0 / 10005 / 10005 *** Base time stamp: 1118429080.4333 [ Fri Jun 10 15:44:40 ADT 2005 ] 4033/1: psargs: /opt/samba/sbin/smbd -D -s/opt/samba/lib/smb.conf 4033/1: poll(0xFFBFF7F0, 3, 60000) (sleeping...) 4033/1: 4.4625 poll(0xFFBFF7F0, 3, 60000) = 1 4033/1: 4.4630 read(5, "\0\0\0 F", 4) = 4 4033/1: 4.4635 read(5, "FF S M B 2\0\0\0\01807C8".., 70) = 70 4033/1: 4.4639 stat64(".", 0xFFBFF878) = 0 4033/1: 4.4644 send(5, "\0\0\0 LFF S M B 2\0\0\0".., 80, 0) = 80 4033/1: 4.4648 time() = 1118429084 4033/1: 4.4659 poll(0xFFBFF7F0, 3, 60000) = 1 4033/1: 4.4662 read(5, "\0\0\0 ^", 4) = 4 4033/1: 4.4665 read(5, "FF S M B 2\0\0\0\01807C8".., 94) = 94 4033/1: 4.4676 stat64("x.cap", 0xFFBFEF20) = 0 4033/1: 4.4681 open("./", O_RDONLY|O_NDELAY|O_LARGEFILE) = 26 4033/1: 4.4685 fstat64(26, 0xFFBFED70) = 0 4033/1: 4.4687 fcntl(26, F_SETFD, 0x00000001) = 0 4033/1: 4.4690 stat64(".//x.cap", 0xFFBFEF20) = 0 4033/1: 4.4694 close(26) = 0 4033/1: 4.4697 send(5, "\0\0\0ACFF S M B 2\0\0\0".., 176, 0) = 176 4033/1: 4.4700 time() = 1118429084 4033/1: 4.4713 poll(0xFFBFF7F0, 3, 60000) = 1 4033/1: 4.4716 read(5, "\0\0\0 F", 4) = 4 4033/1: 4.4719 read(5, "FF S M B 2\0\0\0\01807C8".., 70) = 70 4033/1: 4.4723 stat64(".", 0xFFBFF878) = 0 4033/1: 4.4728 send(5, "\0\0\0 LFF S M B 2\0\0\0".., 80, 0) = 80 4033/1: 4.4731 time() = 1118429084 4033/1: 4.4734 poll(0xFFBFF7F0, 3, 60000) = 1 4033/1: 4.4736 read(5, "\0\0\0 b", 4) = 4 4033/1: 4.4739 read(5, "FF S M BA2\0\0\0\01807C8".., 98) = 98 4033/1: 4.4743 stat64("x.cap", 0xFFBFEFC8) = 0 4033/1: 4.4746 lstat64("x.cap", 0xFFBFEFC8) = 0 4033/1: 4.4749 stat64(".", 0xFFBFEEA8) = 0 4033/1: 4.4752 acl(".", GETACL, 16, 0x0039DC54) = 5 4033/1: 4.4756 send(5, "\0\0\0 #FF S M BA2 "\0\0".., 39, 0) = 39 4033/1: 4.4759 time() = 1118429084 4033/1: 4.4762 poll(0xFFBFF7F0, 3, 60000) = 1 4033/1: 4.4764 read(5, "\0\0\0 X", 4) = 4 4033/1: 4.4767 read(5, "FF S M B 2\0\0\0\01807C8".., 88) = 88 4033/1: 4.4787 stat64("x.cap", 0xFFBFE738) = 0 4033/1: 4.4794 send(5, "\0\0\0 dFF S M B 2\0\0\0".., 104, 0) = 104 4033/1: 4.4799 time() = 1118429084 4033/1: 4.4807 poll(0xFFBFF7F0, 3, 60000) = 1 4033/1: 4.4810 read(5, "\0\0\0 X", 4) = 4 4033/1: 4.4813 read(5, "FF S M B 2\0\0\0\01807C8".., 88) = 88 4033/1: 4.4818 stat64("y.cap", 0xFFBFE738) Err#2 ENOENT 4033/1: 4.4822 stat64("y.cap", 0xFFBFE738) Err#2 ENOENT 4033/1: 4.4825 open(".", O_RDONLY|O_NDELAY|O_LARGEFILE) = 26 4033/1: 4.4827 fstat64(26, 0xFFBFD870) = 0 4033/1: 4.4829 fcntl(26, F_SETFD, 0x00000001) = 0 4033/1: 4.4832 getdents64(26, 0x0038AC38, 8192) = 344 4033/1: 4.4833 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4835 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4836 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4838 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4839 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4841 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4842 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4844 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4845 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4847 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4848 llseek(26, 0, SEEK_CUR) = 512 4033/1: 4.4850 getdents64(26, 0x0038AC38, 8192) = 0 4033/1: 4.4851 close(26) = 0 4033/1: 4.4853 stat64("y.cap", 0xFFBFF878) Err#2 ENOENT 4033/1: 4.4860 send(5, "\0\0\0 #FF S M B 2 4\0\0".., 39, 0) = 39 4033/1: 4.4863 time() = 1118429084 4033/1: poll(0xFFBFF7F0, 3, 60000) (sleeping...)
This looks like the bug I already fixed w.r.t. solaris acl checking. Did you try the latest svn code as I asked ? Jeremy.
Compiling the 3.0.15pre2 code now.
3.0.15pre2 has the same behaviour. I can rename and delete files with smbclient, that I can't when using the same credentials from XP. This time, it was compiled with: --with-acl-support \ --with-included-popt \ --localstatedir=/var/lib/samba \ --with-piddir=/var/run \ --with-logfilebase=/var/log/samba \ --with-privatedir=/etc/samba/private \ --with-configdir=/etc/samba \ --with-ads \ --with-winbind \ --with-quotas The share was configured as: [Archive] path = /samba/archive valid users = @XXX\planet-archive-t-m force group = samba read only = No force create mode = 0660 force directory mode = 0770 force directory security mode = 0770 preserve case = No browseable = No The testing user is a member of the AD group planet-archive-t-m. I can create files in the share using XP, but then can't delete or rename them. Using smbclient, with the same credentials, I can delete and rename the files created under XP.
I expect this is fixed in 3.0.21rc1 due to Guenther's PAC work. Please test and let me know.