Hello The bug is that when the disk runs out of space and I am specifically trying to save obviously more data - Samba server lets me save till the last "byte" on disk and then going on message - disk is full. As a result, I get a corrupted file! (the file is not writen till the end) I tried the same scenario but instead of the Samba server was Windows XP server - the problem does not happen again. File remains the same copy and not rewritten in part. Environments Client side OS - Windows XP. Server side OS - Centos 5.5 smb.conf: ----- [global] [mnt2] path =/mnt2/tmp writeable = yes ----- /mnt2 is an ext3 filesystem of 10MB size. I first create a 9MB file and put a 30KB bmp file. Open a 30KB bmp file (Right click, choose Edit), type PrintScreen and Paste the file and try to save. MS Paint must alert - disk space not enough / disk full. After all - bmp file not readable and file bmp size increased. Excuse me for my English. Thank you. Dmitry
Does that also happen if you put strict allocate = yes into your smb.conf file? Thanks, Volker
(In reply to comment #1) > Does that also happen if you put > > strict allocate = yes > > into your smb.conf file? > > Thanks, > > Volker Yes, with "strict allocate = yes" too happens smb.conf may be very simple, or like that [global] pid directory = /opt/samba/run lock directory = /opt/samba/cache private dir = /opt/samba/cache workgroup = HOME server string = Home storage security = share load printers = no printcap name = /dev/null printing = bsd disable spoolss = yes enable spoolss = no show add printer wizard = no max log size = 102400 dns proxy = no allocation roundup size = 0 strict allocate = yes nt acl support = no bind interfaces only = true interfaces = eth0 smb ports = 139 socket options = SO_REUSEADDR TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE unix extensions = no nt pipe support = no map hidden = yes hide dot files = no [homes] browseable = yes printable = no [mnt2] path =/mnt2/tmp writeable = yes
Please upload network traces of both the cases where the file server is a Samba server and the file server is a Windows server. For information on how to create useful network traces please see http://wiki.samba.org/index.php/Capture_Packets For the Windows->Windows network trace please install wireshark on Windows. If those traces do not give the required hints, we might ask you to upload an strace of smbd. For this, please find the smbd pid that is responsible for your client using the "smbstatus" command. Then issue a strace -ttT -p <smbd-pid> -o /tmp/smbd.strace and reproduce the problem. With best regards, Volker Lendecke
Why are you setting "allocation roundup size = 0" ? This is telling the Windows clients there is no allocation chunk size, which probably explains this problem. Jeremy.
Created attachment 6378 [details] Disk image (FAT 32)
Created attachment 6379 [details] Windows Vista - Linux capture
Created attachment 6380 [details] Windows Vista - Windows 7 (SMB) Capture
Created attachment 6381 [details] Windows Vista - Windows 7 (SMB2) Capture
(In reply to comment #4) > Why are you setting "allocation roundup size = 0" ? This is telling the Windows > clients there is no allocation chunk size, which probably explains this > problem. > > Jeremy. Hello Let me explain some tests and results. First of all, prepare. I used 'imdisk' to create virtual disk on windows. http://www.ltr-data.se/files/imdiskinst.exe I create 10MB disk and make FAT file system. Disk image attached here (disk.img) On disk: approximate 9.5MB dummy file and test.bmp (196KB) in root. Test #1 - Windows Vista (Client) - Linux (194.87.37.17) Attached capture file - Samba358ServSMB.pcap Steps: A) Mount disk.img on linux box. mount -o loop,user,uid=nobody disk.img /drv1 B) Running smbd with config (I tried with "allocation roundup size = 0" and without, same result): [global] pid directory = /opt/samba/run lock directory = /opt/samba/cache private dir = /opt/samba/cache workgroup = HOME server string = Home storage security = share load printers = no printcap name = /dev/null printing = bsd disable spoolss = yes enable spoolss = no show add printer wizard = no max log size = 102400 dns proxy = no strict allocate = yes nt acl support = no bind interfaces only = true interfaces = eth1 smb ports = 445 socket options = SO_REUSEADDR TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE unix extensions = no nt pipe support = no [homes] browseable = yes printable = yes [mnt2] path = /drv1 read only = no guest ok = yes follow symlinks = no #-------------------------------- C) On Windows Vista map \\194.87.37.17\mnt2 as drive Y: D) Start Wireshark capture. E) Reproduce... - Open My Computer window, open disk Y: - Right click on test.bmp -> Edit - Type PrintScreen on keyboard and paste screen image into MS Paint editor. Now test.bmp image size bigger then was before paste. - Click menu File -> Save. - MS Paint waiting.. Then alert window with msg - Disk is full, cant save. - Close MS Paint. Dialog save or not? - click don't save. - Check test.bmp file size, it is now about 600KB (instead 196KB) - Stop capture. Test #2 - Windows Vista (Client) - Windows 7 (Shared server, 192.168.1.34) Attached capture files: Win7ServSMB.pcap - SMB Protocol Win7ServSMB2.pcap - SMB2 Protocol Steps: A) On Windows 7 i have mount disk.img with ImDisk util. Now I have new mounted disk G: B) Share disk G: with full access C) On Windows Vista map \\192.168.1.34\g as drive Y: D) Start Wireshark capture. E) Reproduce... - Open My Computer window, open disk Y: - Right click on test.bmp -> Edit - Type PrintScreen on keyboard and paste screen image into MS Paint editor. Now test.bmp image size bigger then was before paste. - Click menu File -> Save. - MS Paint waiting.. Then alert window with msg - Disk is full, cant save. - Close MS Paint. Dialog save or not? - click don't save. - Check test.bmp file size, it is still 196KB without changes. - Stop capture. Ok, now very interesting thing! I have made another test. Windows XP (Client) and Windows 2003 Shared server. All steps like above. In this case, like in test Samba, test.bmp file size increased too, about 600KB after try to save. And test.bmp not readable. My resume: In Windows 7 this bug was solved, but Windows 2003 (may be XP too) and Samba with this bug. Thanks Dmitry
It's really, really strange. The Vista->Linux capture does not contain ANY attempts at all to modify the file. I don't understand at all how Samba should have destroyed that file. Is this maybe a caching effect of the SMB1 redirector? What happens if you disconnect and reconnect? Volker
What I could also imagine is that this is a bug triggered by your smb.conf file. security=share, nt pipe support = no, all these are options that are not much used these days. Samba does support them, but they present a very unusual kind of file server to the Windows client. This might make it excercise code paths it never excercises usually, triggering bugs. With best regards, Volker
(In reply to comment #11) > What I could also imagine is that this is a bug triggered by your smb.conf > file. security=share, nt pipe support = no, all these are options that are not > much used these days. Samba does support them, but they present a very unusual > kind of file server to the Windows client. This might make it excercise code > paths it never excercises usually, triggering bugs. > > With best regards, > > Volker Hi, I dont't know caching or not. I have simplified my tests. Now, I have 3 PC boxes 1# - Windows Vista (smb client role) IP 192.168.101.70 2# - Windwos XP (smb server) IP 192.168.101.25 3# - CentOS (Samba server) IP 194.87.37.17 2 and 3 PC box have mount disk.img as local volume and share it. In this test SMB protocol used (not SMB2) First test (Vista - Samba) Capture from Vista box: VistatoSamba.pcap Samba log: smbd.VISTAtoSAMBA.log -Edit test.bmp file. -Save - Error - Disk is full. -File test.bmp corrupted! Second test (Vista - XP) Capture from Vista box: VistatoXP.pcap -Edit test.bmp file. -Save - Error - Disk is full. -File test.bmp not changed! Could you reproduce this? I think, the bug is obvious. In this test, client software not changed, protocol not changed, only servers, XP correct, Samba not. My current smb.conf ----------------------- [global] pid directory = /opt/samba/run lock directory = /opt/samba/cache private dir = /opt/samba/cache log file = /opt/samba/smbd.VISTAtoSAMBA.log log level = 10 security = share max log size = 1024000 bind interfaces only = true interfaces = eth1 smb ports = 445 [homes] browseable = yes printable = yes [mnt2] path = /drv1 read only = no guest ok = yes ------------------------------------- If I can do something for you - please ask me. Thank you. Dmitry.
Created attachment 6384 [details] VistatoSamba capture
Created attachment 6385 [details] VistatoXP capture
Created attachment 6386 [details] VISTAtoSAMBA.log
Thanks. In these traces there *are* modifying commands. Windows is trying to expand the file in-place. We are doing the ftruncate call to extend the file. This fails when it detects the disk is full (FAT can't do non-sparse files). But probably FAT leaves the file at the size when it detects the DISK_FULL condition and does not roll back its changes. We need to implement code to do that in user space. Volker
(In reply to comment #16) > to extend the file. This fails when it detects the disk is full (FAT can't do > non-sparse files). But probably FAT leaves the file at the size when it detects Correction in double-negate: FAT only does non-sparse. Volker
(In reply to comment #17) > (In reply to comment #16) > > to extend the file. This fails when it detects the disk is full (FAT can't do > > non-sparse files). But probably FAT leaves the file at the size when it detects > > Correction in double-negate: FAT only does non-sparse. > > Volker Thank you! Dear Volker Lendecke, Could you check with ext3/ext4 FS too? Cause first time I found this bug on ext4 partition. Dmitry.
I did not reproduce this at all yet, this is from pure log analysis. I would expect ext3/ext4 to be a different problem. I would expect the ftruncate to go through but the later writes to fail. We can't do anything about that without "strict allocate = yes". Volker
(In reply to comment #19) > I did not reproduce this at all yet, this is from pure log analysis. I would > expect ext3/ext4 to be a different problem. I would expect the ftruncate to go > through but the later writes to fail. We can't do anything about that without > "strict allocate = yes". > > Volker Please look at http://lists.samba.org/archive/samba/2011-April/161993.html I can reproduce this with empty [global] section, EXT3 filesystem on Debian lenny. and Windows XP SP3.
Created attachment 6395 [details] Level.10 log and packet capture at the same operation My smb.conf: [global] [mnt1] path = /mnt2/tmp writeable = yes The reason why sharename is "mnt1" is only my misspell.
Hello! Dear Samba dev. team, is not this bug forgotten? :) Thanks Dmitry
What do you want us to do? I don't see how this can happen with strict allocate = yes This is a problem with your application not responding correctly to a DISK_FULL response to a write call. If you use "strict allocate = yes", this will behave differently. Volker
(In reply to comment #23) > What do you want us to do? I don't see how this can happen with > > strict allocate = yes > > This is a problem with your application not responding correctly to a DISK_FULL > response to a write call. If you use "strict allocate = yes", this will behave > differently. > > Volker As I mentioned in comment #20, "strict allocate = yes" does not solve this problem. And using mspaint.exe, I can reproduce this problem, see http://lists.samba.org/archive/samba/2011-April/161993.html
Sorry, but in neither of those comments nor in the mailing list post I see strict allocate = yes in the sample smb.conf files.
(In reply to comment #25) > Sorry, but in neither of those comments nor in the mailing list post I see > > strict allocate = yes > > in the sample smb.conf files. Sorry, but at the time I posted http://lists.samba.org/archive/samba/2011-April/161993.html , I also examined "strict allocate = yes". And now I examined again with Samba 3.5.10 and found this problem is reproduced. My smb.conf is ----- [global] strict allocate = yes # this problem occurs regardless of "strict allocate" [mnt1] path = /mnt1/tmp writeable = yes # I examined using EXT3. ----- To reproduce Step 1: Mount small partition for example: # dd if=/dev/zero of=/tmp/image1 bs=1024 count=10000 # losetup /dev/loop1 /tmp/image1 # losetup /dev/loop1 # mke2fs /dev/loop1 # mount /dev/loop1 /mnt1 # mkdir /mnt1/tmp; chmod 1777 /mnt1/tmp Step 2: Create smb.conf shown and start Samba Step 3: Create a bmp file smaller than the partition Step 4: just edit the bmp file (Right click, choose Edit), paste a new image bigger than the partition and save. I use my desktop capture. Paint must alert - disk space not enough / disk full. After all - the bmp file corrupted and its size increased.
Just did exactly those steps. Yes, the file is modified even with strict allocate = yes. But -- this also happens against Windows. It does behave slightly differently on the network, but after the "save" operation the file is modified. It might be that it is not corrupted, but it is enlarged up to the disk full condition.
May be its interesting. I has made many different test configurations. Mix WinXP, WinVista, Win7, Win2003 and mix server and client role in tests scenarios. So, some of test was fail (File size increased) See my Comment 9
Created attachment 6740 [details] Trace against w2k8 Hmm. This is a trace against W2k8. Yet another way to deal with this. Write&x is reported as DISK_FULL, but a later trans2 SETFILEINFO EOF is done successfully. This is different from the VistaToXP capture. This trace is from a "save" operation from mspaint enlarging an existing file beyond the disk size, server is W2k8.
Created attachment 6741 [details] Trace against Samba Same operations against Samba. Slightly different behaviour. This *might* have to do with the allocation roundup size. I'm not sure we will be able to properly fix this for all situations.
(In reply to comment #28) > May be its interesting. > > I has made many different test configurations. > Mix WinXP, WinVista, Win7, Win2003 and mix server and client role in tests > scenarios. > So, some of test was fail (File size increased) > > See my Comment 9 I did test from XP against W2k8 as server. From all I know w2k8 is the same smb server code as Win7 is, so your comment that Win7 fixes it seems not 100% reliable. I did fill up a NTFS volume, in case this matters.
My latest success test configuration was win7 server, winVista client, SMB2 protocol, FAT32. In this test file not increased, all good.
Ok, closing this as INVALID. I have now tried to reproduce this with Windows 7 and Windows XP as clients against W2k8 with an almost-full NTFS and an almost-full FAT. In all 4 cases the file was enlarged. I am just not able to find a way to see the "correct" behaviour on the network using just Windows on both client and server side. To me this is the very definition of "works as designed", thus I'm calling this bug INVALID. You might want to contact Microsoft for finding instructions how to make Windows reliably behave the way you expect it to. Please re-open if this information is available, so that Samba can then emulate the correct behaviour. Volker