When full_audit is used, client can't copy, move, rename or delete large files from samba share. The problem does exist in samba versions 3.5.0rc3-55rc3.fc14 and 3.5.2-59.fc13. The problem doesn't exist in samba version 3.4.7-58.fc12. Our samba server is Linux Fedora 12. Shortly, experiments we did are: PART 1: Use smb.conf with full_audit 1) Try to rename file (size 200Mb). Ok, file renamed. 2) Try to rename file (size 2,9Gb). No, file not renamed. Client got message: "Cannot rename filename: The specified server cannot perform the requested operation." Also file cannot be moved, copied etc. PART 2: Switch off full_audit 1) Try to rename file (size 200Mb). Ok, file renamed. 2) Try to rename file (size 2,9Gb). Ok, file renamed. PART 3: What samba clients? We found that this problem exists when someone connected to samba share from: Windows XP, Windows 7, Windows Vista, Windows 2000 server. Problem does not exist when when someone connected to samba share from Windows 2003 server or from linux Fedora 12 smbclient.
Created attachment 5664 [details] smb.conf To switch off full_audit we just commented strings 68-73.
Can you please upload a debug level 10 log of smbd during the failure to rename that big file? Thanks, Volker
Created attachment 5665 [details] logfile User entered into samba share and tried to rename file. He got error message, and immediately I copied logfile to another folder. Our current samba version is 3.5.2-59.fc13.
That's strange. I don't even see an attempt to rename that file. Would it also be possible to not have the logfile in the same directory as the the file that your user is about to rename? This clutters the logfile considerably. Would it be possible that you create network traces of both the successfull and unsuccessful attempts to rename that file (i.e. with and without full_audit)? Information on how to create useful network traces can be found under http://wiki.samba.org/index.php/Capture_Packets Thanks, Volker
As I hope, in our system all samba logs are living in the /var/log/samba directory, not in samba shares, so log's place can not be the reason of corruption. I did not attach audit logfile, because it contains only connect-disconnect messages. If you need it, please, write. As for network traces, I never did it before, but I'll try to do my best..
Created attachment 5666 [details] tcpdump: full_audit is on, rename unsuccessful The command I used for tcpdump is: tcpdump -p -s 0 -w /home/samba_log/tcpdump.txt port 445 or port 139.
Created attachment 5667 [details] tcpdump: full_audit is off, rename successful
To be on the safe side: dumps were made with log level = 0 in smb.conf file.
Can you please upload the network trace of the successful rename from the beginning of the TCP connection, like you did for the failed attempt? Thanks, Volker
Created attachment 5668 [details] tcpdump: full_audit is off, rename successful Unfortunately, I don't know what I did wrong the first time. I thought two tcpdumps were made the same way. Today we work with another samba user, so there are two new dumps: successful and unsuccessful. User's actions are: 1) connect to share 2) rename/try to rename file (if rename is unsuccessful - click on windows message) 3) disconnect
Created attachment 5669 [details] tcpdump: full_audit is on, rename unsuccessful
Created attachment 5670 [details] minimal smb.conf In order to exclude side effects of complicated configuration I reproduced this issue on samba with simpler configuration. No things like domain controllers and so on, just samba server. Config file is attached.
Created attachment 5672 [details] Patch for 3.5 99% this is another incarnation of bug 7326. Sorry for not also fixing it in 3.5 immediately. The attached patch should fix it. Thanks for the logs, Volker
Comment on attachment 5672 [details] Patch for 3.5 Looks good to me.
Re-assigning to Karolin for inclusion in the next 3.5.x.
We tested this patch and problem is solved. Thank you!
Pushed to v3-5-test. Closing out bug report. Thanks!