Sparc Solaris / UFS file system. I have some ACL's set up for a handful
of users and its all worked flawlessly with every incarnation of Samba
I've used over the past couple years, which would be most.
Last Friday evening I upgraded from 3.0.11 to 3.0.13 and some of the users
I have some ACL's set up for promptly found Monday that they couldn't
save
new Excel files, they'd be informed the file already exists be prompted to
overwrite and then be informed the folder is marked read only. They end
up with two 0 byte files, one with the name they where trying to save the
Excel file as and another of the form fsaxx.tmp.
So Tuesday afternoon I reverted the less crucial Samba servers back to
3.0.11 and came in at 6:30AM Wednesday to revert the other servers back to
3.0.11. Everything is gravy with 3.0.11 as it always been.
I noticed 3.0.14 and 3.0.15pre had been up and back down. But the change
logs where there and mentioned items dealing with ACLs so I thought I'd
hold off posting to this forum and see if a new Samba would fix it.
I downloaded 3.0.14a today, compiled, and tested. Sadly, No! The same
problem is there. Just before I began posting this very message I came
across the thread "ACL and delete files" and it turns out what the
numerous messages in that thread are describing is exactly what I'm seeing
to. I had thought it was more of an Excel thing but as I've tested it
today in conjunction with 3.0.14a it turns it is a general thing, exactly
as that thread describes - a file can be created or modified, but not
deleted or renamed.
Actually, I have determined one additional interesting item not in that
other thread -- Windows XP SP1 works fine with a directory using ACLs with
3.0.13 and 3.0.14a IF AND ONLY IF you do not have Microsoft patch KB885835
installed. XP with SP2 is always screwed. I've only tested with one Win
2K system and it exhibits the same problem with the new Sambas as well.
The problem is totally reproducible across different boxes here and even
using the most very basic of a smb.conf. User schaefer should be able to
connect to his home share, go into his tmp/crap/ folder and create,
modify, and delete files as he pleases. In any Samba 3.0.11 or prior he
can. Haven't tried 3.0.12. 3.0.13 and 3.0.14a he can't...
root@huckfinn:/accounts/staff/schaefer/tmp bash# ls -ld crap
d---------+ 2 root root 512 Apr 15 11:15 crap/
root@huckfinn:/accounts/staff/schaefer/tmp bash# getfacl crap
# file: crap
# owner: root
# group: root
user::---
group::--- #effective:---
group:203:rwx #effective:rwx
group:cfusion:rwx #effective:rwx
mask:rwx
other:---
root@huckfinn:/accounts/staff/schaefer/tmp bash# id schaefer
uid=241(schaefer) gid=60003(cfusion)
root@huckfinn:/accounts/staff/schaefer/tmp bash# cat
/usr/local/samba/lib/smb.conf
# Samba config file created using SWAT
# from TOMCAT.umsl.edu (134.124.15.21)
# Date: 2001/08/31 11:24:37
# Global parameters
[global]
hosts allow = 134.124. 128.206.
workgroup = UMSL
netbios name = HUCKFINN
interfaces = 134.124.15.26 127.0.0.1
bind interfaces only = Yes
security = SHARE
encrypt passwords = Yes
nt acl support = No
name resolve order = lmhosts wins bcast host
os level = 19
preferred master = no
wins server = 134.124.45.45
username map = /usr/local/samba/lib/usernamemap
unix extensions = no
# unix charset = ISO8859-1
smb ports = 139
[Homes]
comment = Home Directories
username = %S
valid users = %S
writeable = Yes
map archive = No
browseable = No
create mask = 664
directory mask = 775
force create mode = 664
force directory mode = 775
Hello, just filed it as #2619. If you wish, put additional information there. Regards, Peter Tom Schaefer wrote:> Sparc Solaris / UFS file system. I have some ACL's set up for a handful > of users and its all worked flawlessly with every incarnation of Samba > I've used over the past couple years, which would be most. > > Last Friday evening I upgraded from 3.0.11 to 3.0.13 and some of the users > I have some ACL's set up for promptly found Monday that they couldn't save > new Excel files, they'd be informed the file already exists be prompted to > overwrite and then be informed the folder is marked read only. They end > up with two 0 byte files, one with the name they where trying to save the > Excel file as and another of the form fsaxx.tmp. > > So Tuesday afternoon I reverted the less crucial Samba servers back to > 3.0.11 and came in at 6:30AM Wednesday to revert the other servers back to > 3.0.11. Everything is gravy with 3.0.11 as it always been. > > I noticed 3.0.14 and 3.0.15pre had been up and back down. But the change > logs where there and mentioned items dealing with ACLs so I thought I'd > hold off posting to this forum and see if a new Samba would fix it. > > I downloaded 3.0.14a today, compiled, and tested. Sadly, No! The same > problem is there. Just before I began posting this very message I came > across the thread "ACL and delete files" and it turns out what the > numerous messages in that thread are describing is exactly what I'm seeing > to. I had thought it was more of an Excel thing but as I've tested it > today in conjunction with 3.0.14a it turns it is a general thing, exactly > as that thread describes - a file can be created or modified, but not > deleted or renamed. > > Actually, I have determined one additional interesting item not in that > other thread -- Windows XP SP1 works fine with a directory using ACLs with > 3.0.13 and 3.0.14a IF AND ONLY IF you do not have Microsoft patch KB885835 > installed. XP with SP2 is always screwed. I've only tested with one Win > 2K system and it exhibits the same problem with the new Sambas as well. > > The problem is totally reproducible across different boxes here and even > using the most very basic of a smb.conf. User schaefer should be able to > connect to his home share, go into his tmp/crap/ folder and create, > modify, and delete files as he pleases. In any Samba 3.0.11 or prior he > can. Haven't tried 3.0.12. 3.0.13 and 3.0.14a he can't... > > root@huckfinn:/accounts/staff/schaefer/tmp bash# ls -ld crap > d---------+ 2 root root 512 Apr 15 11:15 crap/ > > root@huckfinn:/accounts/staff/schaefer/tmp bash# getfacl crap > > # file: crap > # owner: root > # group: root > user::--- > group::--- #effective:--- > group:203:rwx #effective:rwx > group:cfusion:rwx #effective:rwx > mask:rwx > other:--- > > root@huckfinn:/accounts/staff/schaefer/tmp bash# id schaefer > uid=241(schaefer) gid=60003(cfusion) > > root@huckfinn:/accounts/staff/schaefer/tmp bash# cat /usr/local/samba/lib/smb.conf > # Samba config file created using SWAT > # from TOMCAT.umsl.edu (134.124.15.21) > # Date: 2001/08/31 11:24:37 > > # Global parameters > [global] > hosts allow = 134.124. 128.206. > workgroup = UMSL > netbios name = HUCKFINN > interfaces = 134.124.15.26 127.0.0.1 > bind interfaces only = Yes > security = SHARE > encrypt passwords = Yes > nt acl support = No > name resolve order = lmhosts wins bcast host > os level = 19 > preferred master = no > wins server = 134.124.45.45 > username map = /usr/local/samba/lib/usernamemap > unix extensions = no > # unix charset = ISO8859-1 > smb ports = 139 > > [Homes] > comment = Home Directories > username = %S > valid users = %S > writeable = Yes > map archive = No > browseable = No > create mask = 664 > directory mask = 775 > force create mode = 664 > force directory mode = 775 > > > > > >
On Fri, Apr 15, 2005 at 12:03:06PM -0500, Tom Schaefer wrote:> > The problem is totally reproducible across different boxes here and even > using the most very basic of a smb.conf. User schaefer should be able to > connect to his home share, go into his tmp/crap/ folder and create, > modify, and delete files as he pleases. In any Samba 3.0.11 or prior he > can. Haven't tried 3.0.12. 3.0.13 and 3.0.14a he can't...Ok, I'll try to reproduce this here before I have to catch the plane to LinuxConfAu. Thanks, Jeremy.
On Fri, Apr 15, 2005 at 12:03:06PM -0500, Tom Schaefer wrote:> > The problem is totally reproducible across different boxes here and even > using the most very basic of a smb.conf. User schaefer should be able to > connect to his home share, go into his tmp/crap/ folder and create, > modify, and delete files as he pleases. In any Samba 3.0.11 or prior he > can. Haven't tried 3.0.12. 3.0.13 and 3.0.14a he can't... > > root@huckfinn:/accounts/staff/schaefer/tmp bash# ls -ld crap > d---------+ 2 root root 512 Apr 15 11:15 crap/ > > root@huckfinn:/accounts/staff/schaefer/tmp bash# getfacl crap > > # file: crap > # owner: root > # group: root > user::--- > group::--- #effective:--- > group:203:rwx #effective:rwx > group:cfusion:rwx #effective:rwx > mask:rwx > other:--- > > root@huckfinn:/accounts/staff/schaefer/tmp bash# id schaefer > uid=241(schaefer) gid=60003(cfusion)Ok, I'm trying to reproduce this here with a Windows XP Professional SP2 box and Linux ext3+ea+acl filesystem and I can't. Here is my test setup : # ls -ld /tmp/crap d---rwx---+ 2 root root 4096 Apr 15 11:05 /tmp/crap # getfacl crap # file: crap # owner: root # group: root user::--- user:jeremy:rwx group::--- group:jeremy:rwx mask::rwx other::--- User jeremy can create/delete and modify files from a cmd.exe shell and Windows explorer to his hearts content, no problems. It's possible this is a Solaris specific issue. Can you reproduce the problem with 3.0.14a on a Linux box ? Jeremy.
I'm pretty sure I did (though it's Friday and I have a significantly shorter attention span/less attention for detail) and I sent you (JRA directly) logfiles and a configuration file for a 3.0.14a test on RHEL 3.> -----Original Message----- > From: samba-bounces+eric=lib.usf.edu@lists.samba.org > [mailto:samba-bounces+eric=lib.usf.edu@lists.samba.org] On > Behalf Of Jeremy Allison > Sent: Friday, April 15, 2005 2:29 PM > To: Tom Schaefer > Cc: samba@lists.samba.org > Subject: Re: [Samba] still ACL bug in 3.0.14a > > On Fri, Apr 15, 2005 at 12:03:06PM -0500, Tom Schaefer wrote: > > > > The problem is totally reproducible across different boxes > here and even > > using the most very basic of a smb.conf. User schaefer > should be able to > > connect to his home share, go into his tmp/crap/ folder and create, > > modify, and delete files as he pleases. In any Samba > 3.0.11 or prior he > > can. Haven't tried 3.0.12. 3.0.13 and 3.0.14a he can't... > > > > root@huckfinn:/accounts/staff/schaefer/tmp bash# ls -ld crap > > d---------+ 2 root root 512 Apr 15 11:15 crap/ > > > > root@huckfinn:/accounts/staff/schaefer/tmp bash# getfacl crap > > > > # file: crap > > # owner: root > > # group: root > > user::--- > > group::--- #effective:--- > > group:203:rwx #effective:rwx > > group:cfusion:rwx #effective:rwx > > mask:rwx > > other:--- > > > > root@huckfinn:/accounts/staff/schaefer/tmp bash# id schaefer > > uid=241(schaefer) gid=60003(cfusion) > > Ok, I'm trying to reproduce this here with a Windows XP > Professional SP2 > box and Linux ext3+ea+acl filesystem and I can't. > > Here is my test setup : > > # ls -ld /tmp/crap > d---rwx---+ 2 root root 4096 Apr 15 11:05 /tmp/crap > > # getfacl crap > > # file: crap > # owner: root > # group: root > user::--- > user:jeremy:rwx > group::--- > group:jeremy:rwx > mask::rwx > other::--- > > User jeremy can create/delete and modify files from a cmd.exe shell > and Windows explorer to his hearts content, no problems. > > It's possible this is a Solaris specific issue. Can you reproduce > the problem with 3.0.14a on a Linux box ? > > Jeremy. > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/listinfo/samba > >
I've the same problem with AIX 4.3.3 and samba 3.0.13 (bug report #2606) users can create and write, but cannot delete and rename I'll try 3.0.14a but I don't think this would resolve anything
Okay: 3.0.14a RHEL 3, client is a Windows 2003 Server SP 1. Simple (minimally sanitized) configuration using Winbind and Samba: ===== Begin Config ====[global] load printers = no guest account = nobody hosts allow = (our local ranges) workgroup = (our domain) security = domain password server = * client schannel = no encrypt passwords = yes local master = no os level = 1 wins server = (the wins server IP) preserve case = yes invalid users = root mail daemon log level = 10 debug uid = yes debug pid = yes log file = /usr/local/samba/var/log.%m lock directory = /usr/local/samba/var/locks share modes = yes allow trusted domains = no winbind separator = + winbind uid = 12500-19999 winbind gid = 12500-19999 winbind enum users = yes winbind enum groups = yes winbind use default domain = no template homedir = /dev/null [junk] comment = junk test browseable = yes force create mode = 0664 force directory mode = 0775 force group = mysql # a linux group that group owns junk follow symlinks = no path = /usr/local/samba/junk valid users = @(winbind enumerated group) read only = no ====== End Config ===== Taking a file as a valid user and copying it to the destination succeeds. Here's the long ls of the junk dir: # l junk total 5560 drwxrwxr-x 2 bb mysql 4096 Apr 15 15:32 ./ drwxr-xr-x 11 root root 4096 Apr 15 15:21 ../ -rwxrw-r-- 1 LIB+eric mysql 5668947 Mar 25 09:11 HPLJ4250-070323-ILLiad.pdf* Ignoring the minor issue of the created files perms not matching the force create mode (I know it's now an OR thing that I can fix), I should still be able to delete this file, as I've been forced to the mysql group properly (as evidenced by the fact that the file was given that group). But I can't. Jeremy: if you want the logs from this box, let me know - they'll be about 4-5 MB.> -----Original Message----- > From: samba-bounces+eric=lib.usf.edu@lists.samba.org > [mailto:samba-bounces+eric=lib.usf.edu@lists.samba.org] On > Behalf Of Peter Kruse > Sent: Friday, April 15, 2005 3:30 PM > To: Tom Schaefer > Cc: samba@lists.samba.org; jra@samba.org > Subject: Re: [Samba] still ACL bug in 3.0.14a > > Tom Schaefer wrote: > > Sigh. Good catch Peter but I set up my test environment > (Sparc Solaris 8, > > UFS filesystem) to match what Jeremy used and still have the same > > problem. > > but what permissions do the _files_ have that you can no > longer modify? > > > > > User schaefer still can't rename or delete files in the > crap directory. > > > > How frustrating. Jeremy we don't do a lot of Linux around > here but yes I > > should be able to cobble a test together. > > > > Also, Peter, I know you use Linux and have been seeing > these exact same > > symptoms, but have you actually tried it against 3.0.14a yet? > > > > to be honest - no. If you cannot reproduce it, Jeremy, then > I will try > 3.0.14a. > > Peter > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/listinfo/samba > >
Stewart, Eric wrote: ...> > # l junk > total 5560 > drwxrwxr-x 2 bb mysql 4096 Apr 15 15:32 ./ > drwxr-xr-x 11 root root 4096 Apr 15 15:21 ../ > -rwxrw-r-- 1 LIB+eric mysql 5668947 Mar 25 09:11 > HPLJ4250-070323-ILLiad.pdf* >does solaris "ls" not indicate ACLs with a "+"? What does getfacl HPLJ4250-070323-ILLiad.pdf give? Ptr
I still have the bug after upgrading to 3.0.14a logfile [2005/04/15 16:18:28, 10] smbd/statcache.c:stat_cache_lookup(243) stat_cache_lookup: lookup succeeded for name [CBBSP/CBBSP6/NEW TEXT DOCUMENT.TXT] -> [CBBSP/CBBSP6/New Text Document.txt] [2005/04/15 16:18:28, 10] smbd/reply.c:can_delete(1502) can_delete: CBBSP/CBBSP6/New Text Document.txt, dirtype = 0 [2005/04/15 16:18:28, 8] smbd/dosmode.c:dos_mode(283) dos_mode: CBBSP/CBBSP6/New Text Document.txt [2005/04/15 16:18:28, 8] smbd/dosmode.c:dos_mode_from_sbuf(151) dos_mode_from_sbuf returning a [2005/04/15 16:18:28, 8] smbd/dosmode.c:dos_mode(315) dos_mode returning a [2005/04/15 16:18:28, 10] smbd/posix_acls.c:check_posix_acl_group_write(3912) check_posix_acl_group_write: file CBBSP/CBBSP6 failed to match on user or group in token (ret = -1). [2005/04/15 16:18:28, 10] smbd/posix_acls.c:check_posix_acl_group_write(3919) check_posix_acl_group_write: file CBBSP/CBBSP6 returning (ret = -1).
I could swear I did - and according to the config.log in the source directory, I did. However, it looks like it may have failed to find a required lib ... I'll look at it Monday. -----Original Message----- From: Jeremy Allison [mailto:jra@samba.org] Sent: Friday, April 15, 2005 6:28 PM To: Stewart, Eric Cc: samba@lists.samba.org Subject: Re: [Samba] still ACL bug in 3.0.14a On Fri, Apr 15, 2005 at 03:49:47PM -0400, Stewart, Eric wrote:> > Ignoring the minor issue of the created files perms not matchingthe> force create mode (I know it's now an OR thing that I can fix), I > should still be able to delete this file, as I've been forced to the > mysql group properly (as evidenced by the fact that the file was given> that group). > > But I can't.Ensure you've compiled with --with-acl-support. That will fix it. Jeremy.
Ah ha! Okay it turns out libacl-devel wasn't installed on my system. And Red Hat says you need to add acl to /etc/fstab. Well, I can get the compile done but I can't (well, won't) test from home. If it doesn't work Monday and I can't figure it out, you'll get another annoying message from me.> -----Original Message----- > From: Jeremy Allison [mailto:jra@samba.org] > Sent: Friday, April 15, 2005 6:28 PM > To: Stewart, Eric > Cc: samba@lists.samba.org > Subject: Re: [Samba] still ACL bug in 3.0.14a > > On Fri, Apr 15, 2005 at 03:49:47PM -0400, Stewart, Eric wrote: > > > > Ignoring the minor issue of the created files perms not > matching the > > force create mode (I know it's now an OR thing that I can fix), I > > should still be able to delete this file, as I've been > forced to the > > mysql group properly (as evidenced by the fact that the > file was given > > that group). > > > > But I can't. > > Ensure you've compiled with --with-acl-support. That will fix it. > > Jeremy. > >
RHEL 3 AS here - test box (via VPN - I'm so interested in this issue that I'm working on it from home) gave same behavior. Jeremy got an email from me this morning with log files, configuration file, getfacl's, ls -la, and an ldd of smbd showing that the ACL lib was compiled in. Tripwire screamed bloody murder this morning as well on the box since I added acl to the /etc/fstab of the partition where the smb share is and rebooted yesterday, noting there were no ACLs before and now they are there. So near as I know I have everything compiled/configured right (Jeremy will have to confirm this, but it wouldn't surprise me if he said I was missing something) and I'm running into the can't delete thing. Of course, he is at a conference so we probably won't be hearing back until he gets back ...> -----Original Message----- > From: samba-bounces+eric=lib.usf.edu@lists.samba.org > [mailto:samba-bounces+eric=lib.usf.edu@lists.samba.org] On > Behalf Of Schaefer Jr, Thomas R. > Sent: Saturday, April 16, 2005 11:00 AM > To: Jeremy Allison > Cc: samba@lists.samba.org > Subject: RE: [Samba] still ACL bug in 3.0.14a > > > Just making sure everyone knows before I get on the plane :-). > > > > You *must* have configured with --with-acl-support for this to > > successfully work with ACLs on 3.0.14a. > > > > If you don't you get the symptoms you're reporting. > > > > Jeremy. > > Aaarrrggghhh!! > > No no no, I can hardly believe this. I've continued to fight > with this from home last evening and this morning. I have > recompiled 3.0.14a on Solaris in a brand new fresh extract of > the source code from the tar.gz distribution file. smbd -b | > grep -i acl run against the ealier samba's I was producing > where I did not specify --with-acl-support shows this.. > > HAVE_SYS_ACL_H > HAVE_NO_ACLS > HAVE__ACL > HAVE__FACL > > The same with my new smbd configured --with-acl-support shows.. > > HAVE_SYS_ACL_H > HAVE_SOLARIS_ACLS > HAVE__ACL > HAVE__FACL > > So the configure option seems to be "taking". Guess what?? > No difference in the end. Same same same behaviour. Can > create or modify files but not delete or rename them. > > I recompiled on the RedHat Linux box this morning. Where > smbd -b | grep -i acl against the binary I made yesterday yields.. > > HAVE_SYS_ACL_H > HAVE_NO_ACLS > > Today, after reconfiguring and recompiling, smbd -b | grep -i > acl yields.. > > HAVE_SYS_ACL_H > HAVE_POSIX_ACLS > > So the configure option seems to be "taking". So, I tried > it. Guess what?? NO DIFFERENCE (I'm not shouting at anyone > just shouting). Like on the Solaris box, in the interest of > saving time I had just done a reconfigure and recompile of > the same source I had been using yesterday. So, in the > interest of being thorough, like on the Solaris box, I > started over yet again, completely from scratch using a brand > new extract of the samba distribution. Still no dice. After > Jeremy's confidence yesterday I thought for sure it was going > to work on the Linux box. > > I can hardly believe it. I'm eagerly awaiting the results > some of the rest of you get when configuring > --with-acl-support and recompiling. > > Tom Schaefer > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/listinfo/samba > >
If someone has this working on Red Hat Enterprise Linux 3, I'd like a few pointers. I've changed "defaults" in /etc/fstab for the affected partition to "defaults,acl,user_xattr" and rebooted the box. I've gone so far as to make sure all processes were killed, remove the samba sbin, bin, lib, and include directories, checked to make sure ACL support is being compiled in (ldd even shows libacl.so.1 linked). I've even gotten desperate and and added "delete readonly = yes" and even "nt acl support = no" (in all sorts of combinations) to the junk share in the config below, and yet I still get access denied when attempting to delete a file. ls -laF shows: : ls -laF /usr/local/samba/junk total 5608 drwxrwxr-x 2 bb mysql 4096 Apr 16 00:44 ./ drwxr-xr-x 11 root root 4096 Apr 16 23:20 ../ -rwxrw-r-- 1 LIB+eric mysql 46080 Mar 31 2000 annualreport99.doc* -rwxrw-r-- 1 LIB+eric mysql 5668947 Mar 25 09:11 HPLJ4250-070323-ILLiad.pdf* With the "force group =" set, anyone who qualifies as a valid user should be able to delete the file. But I can't. [global] load printers = no guest account = nobody hosts allow = 131.247.112., 131.247.113. workgroup = LIB security = domain password server = * client schannel = no encrypt passwords = yes local master = no os level = 1 wins server = 131.247.112.6 server string = LIB208 Samba Test preserve case = yes invalid users = root mail daemon log level = 10 debug uid = yes debug pid = yes log file = /usr/local/samba/var/log.%m lock directory = /usr/local/samba/var/locks share modes = yes allow trusted domains = no winbind separator = + winbind uid = 12500-19999 winbind gid = 12500-19999 winbind enum users = yes winbind enum groups = yes winbind use default domain = no template homedir = /dev/null [junk] comment = junk test browseable = yes force create mode = 0664 force directory mode = 0775 force group = mysql follow symlinks = no path = /usr/local/samba/junk valid users = @LIB+Technology read only = no> -----Original Message----- > From: samba-bounces+eric=lib.usf.edu@lists.samba.org > [mailto:samba-bounces+eric=lib.usf.edu@lists.samba.org] On > Behalf Of Jeremy Allison > Sent: Saturday, April 16, 2005 9:59 PM > To: Schaefer Jr, Thomas R. > Cc: samba@lists.samba.org; Jeremy Allison > Subject: Re: [Samba] still ACL bug in 3.0.14a > > On Sat, Apr 16, 2005 at 08:29:31PM -0500, Schaefer Jr, Thomas > R. wrote: > > I'm modifying what I wrote this morning. Compiling > --with-acl-support DOES fix the problem on Linux. Jeremy is > right. Although I had compiled it that way this morning I > was accidentally running one of my earlier compiles. Sorry. > > I have email access now, but not much of a test environment yet. > > This happens a *lot*. People, if you reconfigure and try > again and it still doesn't seem to fix the problem please try > and ensure that you're running your new binaries. This seems > to be a common failure. > > > Unfortunately for me, the fact that I've got it functioning > properly on Linux is worthless to me. All my servers are > Solaris / sparc. The Linux thing was just an exercise to see > if it could be narrowed to a Solaris specific problem. At > this moment, for me, it is a Solaris specific problem as I > have yet to get it to function properly on Solaris. I'm > hoping the concensus here isn't that I now need to go talk to > Sun Microsystems because somehow I'm guessing that avenue > isn't going to get me very far. > > Debug level 10 log from Solaris please. > > Jeremy
This patch appears to have done the trick for me. Thanks Jeremy - personally I think you've gone above and beyond (it's still the weekend!) I guess we'll see this in 3.0.15? ;)> -----Original Message----- > From: Jeremy Allison [mailto:jra@samba.org] > Sent: Sunday, April 17, 2005 3:54 AM > To: Stewart, Eric > Cc: samba@lists.samba.org > Subject: Re: [Samba] still ACL bug in 3.0.14a > > On Sat, Apr 16, 2005 at 11:42:33PM -0400, Stewart, Eric wrote: > > If someone has this working on Red Hat Enterprise Linux 3, I'd > > like a few pointers. > > I've changed "defaults" in /etc/fstab for the affected partition > > to "defaults,acl,user_xattr" and rebooted the box. I've > gone so far as > > to make sure all processes were killed, remove the samba > sbin, bin, lib, > > and include directories, checked to make sure ACL support is being > > compiled in (ldd even shows libacl.so.1 linked). I've even gotten > > desperate and and added "delete readonly = yes" and even > "nt acl support > > = no" (in all sorts of combinations) to the junk share in the config > > below, and yet I still get access denied when attempting to delete a > > file. ls -laF shows: > > > > : ls -laF /usr/local/samba/junk > > total 5608 > > drwxrwxr-x 2 bb mysql 4096 Apr 16 00:44 ./ > > drwxr-xr-x 11 root root 4096 Apr 16 23:20 ../ > > -rwxrw-r-- 1 LIB+eric mysql 46080 Mar 31 2000 > > annualreport99.doc* > > -rwxrw-r-- 1 LIB+eric mysql 5668947 Mar 25 09:11 > > HPLJ4250-070323-ILLiad.pdf* > > > > With the "force group =" set, anyone who qualifies as a valid > > user should be able to delete the file. But I can't. > > Ok, I think I see the bug you're encountering.... I don't > think force group > was considered in the posix_acl code - that changes current_user.gid > without changing it in the group array in current_user. > > Can you try this patch please ? > > Jeremy. >
s?n, 17.04.2005 kl. 15.37 skrev Stewart, Eric:> Actually I did that - covered it in an earlier message in the thread, as Samba won't compile in libacl without the libacl-devel package (that's where the header file it's looking for is). I installed it via up2date.I missed the thread, I'm afraid. That's what you get for breaking threads and continually posting out of thread. For the remainder, there's NO WAY I'm moving from 3.0.11 (which works fine both on this RHAS3 test rig and on a RHAS3 production server) until people stop sending in bug reports for all newer versions. I have to support a potential of 1,150+ users on 75+ Win2k workstations (as well as a plether of other utilities) and I want as little hassle as possible, life is already difficult enough ;) --Tonni -- Nothing sucksseeds like a pigeon without a beak ... mail: tonye@billy.demon.nl http://www.billy.demon.nl They love us, don't they, They feed us, won't they ...
I've tried 3.0.14a this morning with --with-acl-support and it wasn't working. I've applied your patch to posix_acls.c, rebuild everything from scratch and the problem persist. logfile [2005/04/18 11:03:36, 10] smbd/reply.c:can_delete(1502) can_delete: CBBSP/CBBSP6/New Text Document.txt, dirtype = 0 [2005/04/18 11:03:36, 8] smbd/dosmode.c:dos_mode(283) dos_mode: CBBSP/CBBSP6/New Text Document.txt [2005/04/18 11:03:36, 8] smbd/dosmode.c:dos_mode_from_sbuf(151) dos_mode_from_sbuf returning a [2005/04/18 11:03:36, 8] smbd/dosmode.c:dos_mode(315) dos_mode returning a [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2289) Entering sys_acl_get_file [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2290) path_p is CBBSP/CBBSP6 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2309) Got facl and returned it [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_init(2730) Entering sys_acl_init [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_init(2743) Exiting sys_acl_init [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2331) acl_entry is 807235736 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2332) acl_last(file_acl) id 807235736 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2426) i is 1 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2455) idp->id_len = 8 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2480) new_acl_entry->ace_access = 448 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2426) i is 2 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2455) idp->id_len = 8 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2480) new_acl_entry->ace_access = 448 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2426) i is 3 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2455) idp->id_len = 8 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_file(2480) new_acl_entry->ace_access = 0 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2192) This is the count: 0 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2210) *entry_p is 804394468 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2211) *entry_p->ace_access is 448 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_tag_type(2226) the tagtype is 3 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_permset(2253) Starting AIX sys_acl_get_permset [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_permset(2255) **permset_p is 448 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_permset(2262) Ending AIX sys_acl_get_permset [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2192) This is the count: 1 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2210) *entry_p is 804394468 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2211) *entry_p->ace_access is 448 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_tag_type(2226) the tagtype is 4 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_permset(2253) Starting AIX sys_acl_get_permset [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_permset(2255) **permset_p is 448 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_permset(2262) Ending AIX sys_acl_get_permset [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2192) This is the count: 2 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2210) *entry_p is 804394468 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2211) *entry_p->ace_access is 0 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_tag_type(2226) the tagtype is 5 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_permset(2253) Starting AIX sys_acl_get_permset [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_permset(2255) **permset_p is 0 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_permset(2262) Ending AIX sys_acl_get_permset [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2192) This is the count: -1 [2005/04/18 11:03:36, 10] lib/sysacls.c:sys_acl_get_entry(2192) This is the count: -1 [2005/04/18 11:03:36, 10] smbd/posix_acls.c:check_posix_acl_group_write(3912) check_posix_acl_group_write: ret = -1 before check_stat: [2005/04/18 11:03:36, 10] smbd/posix_acls.c:check_posix_acl_group_write(3938) check_posix_acl_group_write: file CBBSP/CBBSP6 failed to match on user or group in token (ret = -1). [2005/04/18 11:03:36, 10] smbd/posix_acls.c:check_posix_acl_group_write(3945) check_posix_acl_group_write: file CBBSP/CBBSP6 returning (ret = -1). [2005/04/18 11:03:36, 3] smbd/error.c:error_packet(129) error packet at smbd/nttrans.c(800) cmd=162 (SMBntcreateX) NT_STATUS_ACCESS_DENIED>From: "Gerald (Jerry) Carter" <jerry@samba.org> >To: Jeremy Allison <jra@samba.org> >CC: Yannick Bergeron <burgergold@hotmail.com> >Subject: Re: [Samba] still ACL bug in 3.0.14a >Date: Sat, 16 Apr 2005 11:52:11 -0500 > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Jeremy Allison wrote: >| On Fri, Apr 15, 2005 at 01:31:40PM -0700, Jeremy Allison wrote: >|>I'm starting to think this is the cause of the problems for people. >|>I can check this by compiling without acl support and seeing if I >|>can reproduce the bug. >| >| Yep - confirmed it. For the people who are reporting this bug, you're >| failing to add the --with-acl-support when configuring Samba. >| >| I agree this is a change compared to 3.0.11, but is obviously >| needed when you're dealing with ACLs. I'll talk with Jerry to >| see if we can get a tech note prepared. > >Jeremy, > >I agree that the current behavior is correct and necessary for >the "can delete" check we need. We'll get something mailed >out on Monday. > > > > > >cheers, jerry >====================================================================>Alleviating the pain of Windows(tm) ------- http://www.samba.org >GnuPG Key ----- http://www.plainjoe.org/gpg_public.asc >"I never saved anything for the swim back." Ethan Hawk in Gattaca >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.5 (GNU/Linux) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFCYUK7IR7qMdg1EfYRAgcDAJ0TvPLcJQ0EHvTdabaK/xXCo6Js2wCg5G3X >BrBDGsPhWX3vXVTBwPUEJ/U>=DaL3 >-----END PGP SIGNATURE-----
I've been messing with it some more. Yeah, you can take ACL's out of
the picture. It basically boils down to in UNIX, even if the owner of
the file does not have write access, if the group does have write access
and you are a member of the group you can write to the file.
With Samba, at least by default, you can't. Its like Peter is saying,
Samba seems to mark the file as read only since the owner doesn't have
write access and that is that. It doesn't matter if the file actually
is writeable by me due to my group membership.
Now I don't know if this is by design, and/or exactly how it can be
finessed into behaving differently via some of those other directives
such as "store dos attributes" and what not. But what I can say is
that
to me nothing seems to have changed as far as all this goes between
3.0.11 and 3.0.14a. I've done some testing of this matter today on both
versions.
Peter, Take a look of this little session log I made a few minutes ago
and see if this basically presents what you are saying...
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\Documents and Settings\schaefert.UMSL-USERS>cd \
C:\>ssh -l schaefer stercus
schaefer@stercus's password:
Last login: Tue Apr 19 15:15:41 2005 from medusa.umsl.edu
Sun Microsystems Inc. SunOS 5.8 Generic February 2000
schaefer@stercus:~ bash$ su -
Password:
Sun Microsystems Inc. SunOS 5.8 Generic February 2000
You have new mail.
# bash
root@stercus:/ bash# cd ~schaefer
root@stercus:/accounts/staff/schaefer bash# mkdir peter
root@stercus:/accounts/staff/schaefer bash# cd peter
root@stercus:/accounts/staff/schaefer/peter bash# echo $TERM
cygwin
root@stercus:/accounts/staff/schaefer/peter bash# export TERM=vt100
root@stercus:/accounts/staff/schaefer/peter bash# echo "some text"
>
newfile.txt
root@stercus:/accounts/staff/schaefer/peter bash# ls -l
total 2
-rw-r--r-- 1 root other 10 Apr 19 2005 newfile.txt
root@stercus:/accounts/staff/schaefer/peter bash# id schaefer
uid=241(schaefer) gid=60003(cfusion)
root@stercus:/accounts/staff/schaefer/peter bash# chgrp 60003
newfile.txt
root@stercus:/accounts/staff/schaefer/peter bash# chmod 060 newfile.txt
root@stercus:/accounts/staff/schaefer/peter bash# ls -l
total 2
----rw---- 1 root cfusion 10 Apr 19 2005 newfile.txt
root@stercus:/accounts/staff/schaefer/peter bash# ls -la
total 36
drwxr-xr-x 2 root other 512 Apr 19 2005 ./
drwx--x--x 84 schaefer staff 16384 Apr 19 2005 ../
----rw---- 1 root cfusion 10 Apr 19 2005 newfile.txt
root@stercus:/accounts/staff/schaefer/peter bash# cat newfile.txt
some text
root@stercus:/accounts/staff/schaefer/peter bash# exit
exit
# exit
schaefer@stercus:~ bash$ export TERM=vt100
schaefer@stercus:~ bash$ cd peter
schaefer@stercus:~/peter bash$ ls -al
total 36
drwxr-xr-x 2 root other 512 Apr 19 2005 ./
drwx--x--x 84 schaefer staff 16384 Apr 19 2005 ../
----rw---- 1 root cfusion 10 Apr 19 2005 newfile.txt
schaefer@stercus:~/peter bash$ echo "In UNIX I can write to newfile.txt
via the
group permission even though the write bit is not set for the owner"
>>
newfile.
txt
schaefer@stercus:~/peter bash$ cat newfile.txt
some text
In UNIX I can write to newfile.txt via the group permission even though
the writ
e bit is not set for the owner
schaefer@stercus:~/peter bash$ id
uid=241(schaefer) gid=60003(cfusion)
schaefer@stercus:~/peter bash$ exit
logout
Connection to stercus closed.
C:\>net use * \\stercus\schaefer
Drive I: is now connected to \\stercus\schaefer.
The command completed successfully.
C:\>i:
I:\>cd peter
I:\peter>dir
Volume in drive I is schaefer
Volume Serial Number is 16CF-28CD
Directory of I:\peter
04/19/2005 03:29p <DIR> .
04/19/2005 03:27p <DIR> ..
04/19/2005 03:31p 121 newfile.txt
1 File(s) 121 bytes
2 Dir(s) 26,087,165,952 bytes free
I:\peter>echo "in windows, i can't write to the file" >>
newfile.txt
Access is denied.
-----Original Message-----
From: Peter Kruse [mailto:pk@q-leap.com]
Sent: Tuesday, April 19, 2005 12:09 PM
To: Schaefer Jr, Thomas R.
Cc: jra@samba.org; samba@lists.samba.org
Subject: Re: still ACL bug in 3.0.14a
Hello,
thanks, I just added a comment to
https://bugzilla.samba.org/show_bug.cgi?id=2619 that shows my
recent findings. It looks like not directly related to ACLs,
but more with "store dos attributes". I still have the feeling
that the behaviour of samba is somewhat not what you'd expect.
Regards,
Peter
Tom Schaefer wrote:> Hello,
>
> I've kind of been hanging with Peter on this whole issue so didn't
> want to just abandon him when Jeremy issued the Solaris patch that
> fixed things for me.
>
> I went and took a hard look at bug report 2619 that Peter filed and
> tried to duplicate it. He is doing ACLs on specific files, not
> directories as I was. When specifically following Peter's
bug report, > I CAN duplicate the bug Peter found under Solaris even with the all
> inclusive force group/Solaris patch Jeremy issued yesterday
installed. > I put the new patch on the Linux box, and as Peter is saying, the
> problem is still there as well. I noticed Jeremy requesting level 10
> debug logs on the bug tracking page. I'll send some as soon as I can.
>
> Tom Schaefer
>
> On Tue, 19 Apr 2005 09:45:46 +0200
> Peter Kruse <pk@q-leap.com> wrote:
>
>
>>Hello again,
>>
>>Jeremy Allison wrote:
>>
>>>On Mon, Apr 18, 2005 at 06:35:12PM +0200, Peter Kruse wrote:
>>>
>>>
>>>>bad news, my problem is not fixed with 3.0.14a
>>>
>>>
>>>The log file helped. Try this patch (applies against
>>>raw 3.0.14a). Problem was Solaris was returning 2 in a
>>>place I expected a 1....
>>>
>>
>>tried it, makes no difference here. I'm neither using "force
group"
>>nor using Solaris. Sorry to confuse you, there are probably two
>>different problems in the same thread, although the subject is valid
>>for both. But as the Solaris issue seems to be resolved, maybe you
>>could have a look at my bug report:
>>https://bugzilla.samba.org/show_bug.cgi?id=2619
>>The bug report includes exact instructions how to reproduce it. I get
>>the impression that the acl implementation is wrong. It looks to me
>>that if any user doesn't have write permission then the group
settings >>are ignored. Jeremy, if you create such a file, do you get correct
>>behaviour?
>>
>>Thx,
>>
>> Peter
>>--
>>To unsubscribe from this list go to the following URL and read the
>>instructions: https://lists.samba.org/mailman/listinfo/samba
>>
Hi,
I can confirm this bug for 3.0.11 as well. We are treating the unix
permissions as a mask for the ACLs at the moment, otherwise we end up
with readonly files etc etc.
I think Peters impression is correct: unix permissions get checked first
and if no 'normal' user has access rights ACL's doe not get checked.
I'll try to get a log file for this if I can get around to setup a test
environment.
Regards,
Bolke
================ Cut From Digest ============Hello again,
Jeremy Allison wrote:
> On Mon, Apr 18, 2005 at 06:35:12PM +0200, Peter Kruse wrote:
>
>>
>> bad news, my problem is not fixed with 3.0.14a
>
>
>
> The log file helped. Try this patch (applies against
> raw 3.0.14a). Problem was Solaris was returning 2 in a
> place I expected a 1....
>
tried it, makes no difference here. I'm neither using "force
group" nor
using Solaris. Sorry to confuse you, there are probably two different
problems in the same thread, although the subject is valid for both.
But as the Solaris issue seems to be resolved, maybe you could
have a look at my bug report:
https://bugzilla.samba.org/show_bug.cgi?id=2619
The bug report includes exact instructions how to reproduce it.
I get the impression that the acl implementation is wrong. It looks
to me that if any user doesn't have write permission then the
group settings are ignored.
Jeremy, if you create such a file, do you get correct behaviour?
Thx,
Peter
Seemingly Similar Threads
- DO NOT REPLY [Bug 7865] New: files or dirs with more than 16 ACLs are not rsynced correctly
- WinXP/x64 - MFC CFile objects leak parent directory handles
- Samba 3 smbstatus not as good
- 3.0.23pre1 does not compile on HP-UX 11i
- Building extlinux (Syslinux 6.03-pre11)