I have a customer that runs cougar mtn accounting (http://www.cougarmtn.com/). Its just a bunch of dbf files stored on a share. Server: SLES10 x86 kernel: 2.6.16-21.0.8-smp (SLES) passdb: ldap pre-upgrade Samba: 3.0.22 (distributed w/ SLES) upgraded-samba: 3.5.8 (enterprisesamba.org) Everything works fine with version 3.0.22. I upgraded samba to v. 3.5.8 for win7 support using the enterprisesamba.org packages for SLES10. After upgrading attempting to login to the acct. application fails with 'wrong password.' Everything else still works perfectly. Reproducible? Yes, every time. I have attached a tarball with: smb.conf (from testparm -s and -sv) Level 10 log.smbd Level 10 log.reception-test (the client pc) smb#.cap (wireshark capture) for both the working 3.0.22 and failing 3.5.8 Please let me know if I can be of any further assistance. Thank you
Created attachment 6389 [details] log files, wireshark caputre, smb.conf from working config
Created attachment 6390 [details] log files, wireshark caputre, smb.conf from failed version
Wild guess: Can you try to set "delete readonly = yes"? Volker
Volker, Thanks for the quick response. That seems to have done it. My test environment allows me to login. I'll have to test it at the client in production to verify everything else works, but i am hopeful. I didnt pick up on that because both versions had it set to the default of NO. If you dont mind, could you explain this a little. It seems that samba changed the way that it handles the operation, even though the config directive is the same. Thanks again, cooper
On Fri, Apr 08, 2011 at 02:57:42PM +0200, samba-bugs@samba.org wrote: > If you dont mind, could you explain this a little. It > seems that samba changed the way that it handles the > operation, even though the config directive is the > same. For some reason the files on your disk are read only. This might have to do with your create mask and other settings. This leads to unlink attempts to return with NT_STATUS_CANNOT_DELETE, which is the correct thing to do for readonly files (see for example frame 10006). Samba 3.5.8 just got more correct in this aspect by default. The alternative (and probably more correct) solution would be to make the files not read only. Volker
Volker, Ok, I have implemented this at the client site, and everything is working well. Thank you (In reply to comment #5) > > For some reason the files on your disk are read only. This > might have to do with your create mask and other settings. create mask/mode sets everything 666. > This leads to unlink attempts to return with > NT_STATUS_CANNOT_DELETE, which is the correct thing to do > for readonly files (see for example frame 10006). Samba > 3.5.8 just got more correct in this aspect by default. The > alternative (and probably more correct) solution would be to > make the files not read only. I think this is more 'awkward' software, or software that is looking for some windows semantics (i should have mentioned that it works fine when shared from a windows XP or 7 machine) than anything. Looking at some of the other frames from around that one, I see that the file is created with 'delete on close.' Its almost like its a test to check access to the share, and then the file is supposed to get removed. You can go ahead and close this, unless you want to look at it further. I appreciate your help. regards, cooper.
Works as designed