Samba 3.0.20 store dos attributes = yes (i.e. there is no readonly attribute on files) User can not write on share Excel - XP,2003 Client OS: Win'98 and WinXP Excel produces a error message when user tries to open XLS file from samba resource.
Created attachment 1440 [details] Sniff of try to open xls file from read-only samba share with MS Excel In my humble opinion this is interesting: Packet #15 - client request to Open AndX file in Read-Write mode Packet #16 - server resposes success error code and returns FID
Created attachment 1441 [details] Sniff of try to open xls file from read-only XP share with MS Excel packet #22: request to open file in read-write mode packet #23: Error: Access Denied packet #25: request to open file in read-only mode packet #31: success Result: Excel normaly opened file in read-only mode
I'll take a look at this as soon as I'm in a place where I can get at my vmware excell sessions. What version of Excel ? Jeremy.
Excel XP I've just verified that Excel 2003 opens file on read-only samba share.
Ok these sniffs are very interesting. Apparently we're allowing an OPEN_AND_X call with read/write request to succeed on a read-only share. I'm going to check that this specific case is fixed in the current SAMBA_3_0_RELEASE code and if so I'll close this one out. Jeremy.
I've tested with smbclient with the current 3.0.20a code and this case is definately denied. I think this bug is fixed with 3.0.20a - please re-open if you can reproduce with 3.0.20a. Thanks, Jeremy.
I've reproduced this problem with 3.0.20a
Created attachment 1465 [details] Sniff of executing echo xxx >file There is a simple way to reproduce this bug without Excel at all. 1. map any read-only samba share as a network drive (e.g. V:) 2. find a file on network drive WITHOUT read-only attribute (e.g. V:\1\test.txt) 3. run echo xxx >file (e.g. echo xxx >V:\1\test.txt) Result: C:\WINDOWS>echo xxx >V:\1\test.txt The network has responded incorrectly. Abort, Fail? Sniff attached. Samba 3.0.20a
Created attachment 1466 [details] Sniff of executing echo xxx >file over XP share The same as previous, but drive was mapped from Windows XP. C:\WINDOWS>echo xxx >V:\1\test.txt File creation error sniff attached
Boy I wish you'd sent these in *before* we shipped 3.0.20a.... That would have enabled us to fix before ship. Jeremy.
This is a different openX request to the previous one. This is a "create if not exist, truncate if exists" call - the previous one (the one I fixed for 3.0.20a) was a "open if exists, fail if not exists" call. Jeremy.
I have tried with a Win98 client and a Samba 3.0.20a server and I can *NOT* reproduce this error with the "echo XXX >\foo" trick. Looking at my sniff I get "Access Denied" on the OpenX with create mode 0x12 (truncate file if not exists, create file if does not exist) and desired access 0x22 (deny write, open for read/write) - exactly the same OpenX call as your sniff. Please check that 3.0.20a is running on your system, the latest sniff you posted looks like a sniff from a 3.0.20 smbd server. Jeremy.
Excuse me, but how can I get 3.0.20a before it was shipped? svn up gave me 3.0.21pre1
Jeremy did you have "store dos attributes = yes" in smb.conf? By default samba sets read-only attribute on every file on read-only share. If file has read-only attribute error can not be reproduced. But if "store dos attributes" is set to yes a file on read-only share but without read-only attribute can exist. On these files error with "echo xxx >file" can be reprodused, i.e. file must not have read-only attribute.
Created attachment 1474 [details] More complicated sniff This can be demonstrated with this sniff. Samba version is 3.0.20a (packet #4) file V:\1\test-ro.txt has read-only attribute, V:\1\test.txt has not. (packet #20 ) echo to file without read-only attribute finished with network error echo to file with read-only attribute finished with access denied
Created attachment 1475 [details] Capture showing what happens on my system. Quite simply this DOES NOT HAPPEN when I try and do what you suggest with Win98 against a Samba 3.0.20a read-only share. Here is the capture trace of when I attempt to do : dir test.txt echo xxx >\test.txt I get "file creation error" (which is the mapping of access denied). Looking at the code in 3.0.20a I cannot see any way that you are getting the results you are getting, which makes me doubt you are running that release. Jeremy.
Created attachment 1476 [details] smbd level 10 log covering the same time as the sniff. Debug level 10 log from smbd covering the same sniff. Note that the file is not shown as read-only. This is working correctly for me. Jeremy
I even downloaded the raw 3.0.20a source code and checked that smbd/open.c is identical to smbd/open.c in the SAMBA_3_0_RELEASE SVN tree. This is the relevent section of smbd/open.c that should make what you're reporting impossible : 1441 /* 1442 * Ensure we can't write on a read-only share or file. 1443 */ 1444 1445 if (flags != O_RDONLY && file_existed && 1446 (!CAN_WRITE(conn) || IS_DOS_READONLY(existing_dos_attributes))) { 1447 DEBUG(5,("open_file_ntcreate: write access requested for " 1448 "file %s on read only %s\n", 1449 fname, !CAN_WRITE(conn) ? "share" : "file" )); 1450 set_saved_error_triple(ERRDOS, ERRnoaccess, 1451 NT_STATUS_ACCESS_DENIED); 1452 errno = EACCES; 1453 return NULL; 1454 } I want you to add level 10 debugs to *your* copy of the samba3.0.20a source code and add an "else" section to this code that will print out all the values of the boolean tests we're doing here. If this is happening I need to be able to do remote debugging... Jeremy.
Created attachment 1481 [details] Yet another sniff dir V:\1\test.txt echo xxx >V:\1\test.txt
Created attachment 1482 [details] Level 10 log covering above sniff This debug log was got on my samba while sniffing.
The debug level 10 log may finally help. It's late here now, I'll go through this carefully early tomorrow morning. Jeremy.
I've set dos attribute mapping, set the file to be ARCHIVE only from a read-write share, then tried the echo >test.txt from the read-only share. I *always* get access denied. Ok - 2 things. I need to see your entire smb.conf and I need to know the mount options you've used to mount the drive on your linux box and I need to know what share you're accessing. I need to have a *complete* script of how to reproduce this. Looking at the source code I posted I *still* cannot see how your test is getting past this part of the code : 1445 if (flags != O_RDONLY && file_existed && 1446 (!CAN_WRITE(conn) || IS_DOS_READONLY(existing_dos_attributes))) { Jeremy.
Created attachment 1483 [details] Patch to give me more info Secondly please add this patch to your source code, recompile and send me the debug level 10 log from your experiment please. Jeremy.
Created attachment 1484 [details] My samba config Comments and empty lines removed via grep -v ^\# smb.conf | grep -v ^\; | egrep -v ^\\s*\$ About server OS: FreeBSD 5.4-STABLE mount options: /dev/da1s1a on /shared (ufs, local, soft-updates, acls) script to reproduce is: create a file without ro attribute execute echo xxx >file from a user having no rights to write to file.
Created attachment 1485 [details] FreeBSD specific patches used to build my samba. My samba was built with this patches from freebsd port.
Created attachment 1486 [details] Lev 10 log file after patching open.c Action on client: echo xxx >V:\1\test.txt Result: The network has responded incorrectly.
UPS! Share is not true read-only! It is writable. But user can not write to file test.txt I'm terribly sorry! But question still exists...
Created attachment 1487 [details] Sniff echo xxx >file on XP share (R/W share R/O file) XP as server in similar situation (RO file on RW share). File test.txt was made non-writable for user by NTFS ACL. Actions on client: C:\WINDOWS>attrib V:\1\test.txt A test.txt V:\1\test.txt C:\WINDOWS>attrib V:\1\test.txt A test.txt V:\1\test.txt C:\WINDOWS>echo xxx >V:\1\test.txt File creation error
Ok this seems to be the amazing mutating bug. This is at least 3 different behaviours you've reported on this. The first one I definately fixed with the patch I added to 3.0.20a. So what we're looking at now is a different bug. The actual problem, as I understand it now is that the share *is* in fact read-write, the file attributes are read/write, but the ACL on the file prevents a user from writing to the file. Correct ? If this is *finally* the actual problem then I'll have time to look at this tomorrow. But first I want to see a confirmation that the case I described above *is actually* the correct description of the problem. I've wasted an amazing amount of time trying to reproduce this with a read-only share and I don't want to waste any more time on a wild goose chase. So I ask again. is the case I described above an accurate description of the bug ? Jeremy.
Yes, you are right. Problem exists if share is read/write, file has not DOS read-only attribute, but file is unwritable by user. Bad description of situation in previous reports is my fault. I am sorry.
Created attachment 1490 [details] Proposed patch. Well I'm glad we tracked this one down - it was a bug introduced in the migration to NTcreate style opens. This patch should fix it. Let me know. Jeremy.
Yes! With you patch the problems with echo xxx > file and with opening unwritable MS Excel file on rw share are fixed! Thank you!
From the looks of it this has been tracked down, but since I'm following up from http://bugs.kde.org/show_bug.cgi?id=109451 I thought I'd mention the fairly easy way to reproduce this that we've stumbled across. Using access() to check the write permissions of a read-only file returns that it is writable -- i.e. : bool File::isWritable(const char *file) { return access(file, W_OK) == 0; } That returns true on a read-only mounted smbfs. However then when opening the file later on opening in read/write mode fails: d->readOnly = !isWritable(file); d->file = fopen(file, d->readOnly ? "r" : "r+"); if(!d->file) debug("Could not open file " + String(file)); i.e. we do in fact see that debug message. So access() is returning that it is writable while the fopen() call for read/write fails.