Bug 8059 - Disk full / save file corrupted
Disk full / save file corrupted
Status: CLOSED INVALID
Product: Samba 3.5
Classification: Unclassified
Component: SMB2
3.5.8
All All
: P5 major
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-05 06:35 UTC by Dmitry
Modified: 2011-08-02 13:52 UTC (History)
2 users (show)

See Also:


Attachments
Disk image (FAT 32) (46 bytes, text/plain)
2011-04-06 08:11 UTC, Dmitry
no flags Details
Windows Vista - Linux capture (512.74 KB, application/octet-stream)
2011-04-06 08:12 UTC, Dmitry
no flags Details
Windows Vista - Windows 7 (SMB) Capture (824.13 KB, application/octet-stream)
2011-04-06 08:13 UTC, Dmitry
no flags Details
Windows Vista - Windows 7 (SMB2) Capture (689.27 KB, application/octet-stream)
2011-04-06 08:14 UTC, Dmitry
no flags Details
VistatoSamba capture (414.42 KB, application/octet-stream)
2011-04-07 09:23 UTC, Dmitry
no flags Details
VistatoXP capture (312.76 KB, application/octet-stream)
2011-04-07 09:23 UTC, Dmitry
no flags Details
VISTAtoSAMBA.log (1.43 MB, text/plain)
2011-04-07 09:24 UTC, Dmitry
no flags Details
Level.10 log and packet capture at the same operation (461.62 KB, application/octet-stream)
2011-04-08 16:57 UTC, TAKAHASHI Motonobu
no flags Details
Trace against w2k8 (166.09 KB, application/octet-stream)
2011-08-01 11:57 UTC, Volker Lendecke
no flags Details
Trace against Samba (120.71 KB, application/x-bzip)
2011-08-01 11:58 UTC, Volker Lendecke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry 2011-04-05 06:35:22 UTC
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
Comment 1 Volker Lendecke 2011-04-05 06:41:02 UTC
Does that also happen if you put

strict allocate = yes

into your smb.conf file?

Thanks,

Volker
Comment 2 Dmitry 2011-04-05 06:49:00 UTC
(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
Comment 3 Volker Lendecke 2011-04-05 06:54:46 UTC
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
Comment 4 Jeremy Allison 2011-04-05 17:04:51 UTC
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.
Comment 5 Dmitry 2011-04-06 08:11:40 UTC
Created attachment 6378 [details]
Disk image (FAT 32)
Comment 6 Dmitry 2011-04-06 08:12:28 UTC
Created attachment 6379 [details]
Windows Vista - Linux capture
Comment 7 Dmitry 2011-04-06 08:13:22 UTC
Created attachment 6380 [details]
Windows Vista - Windows 7 (SMB) Capture
Comment 8 Dmitry 2011-04-06 08:14:08 UTC
Created attachment 6381 [details]
Windows Vista - Windows 7 (SMB2) Capture
Comment 9 Dmitry 2011-04-06 08:15:29 UTC
(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
Comment 10 Volker Lendecke 2011-04-06 16:17:30 UTC
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
Comment 11 Volker Lendecke 2011-04-06 16:20:43 UTC
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
Comment 12 Dmitry 2011-04-07 09:21:35 UTC
(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.
Comment 13 Dmitry 2011-04-07 09:23:12 UTC
Created attachment 6384 [details]
VistatoSamba capture
Comment 14 Dmitry 2011-04-07 09:23:49 UTC
Created attachment 6385 [details]
VistatoXP capture
Comment 15 Dmitry 2011-04-07 09:24:47 UTC
Created attachment 6386 [details]
VISTAtoSAMBA.log
Comment 16 Volker Lendecke 2011-04-07 09:35:37 UTC
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
Comment 17 Volker Lendecke 2011-04-07 09:38:45 UTC
(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
Comment 18 Dmitry 2011-04-07 09:46:55 UTC
(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.
Comment 19 Volker Lendecke 2011-04-07 09:52:45 UTC
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
Comment 20 TAKAHASHI Motonobu 2011-04-08 16:31:55 UTC
(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.
Comment 21 TAKAHASHI Motonobu 2011-04-08 16:57:36 UTC
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.
Comment 22 Dmitry 2011-07-28 13:31:26 UTC
Hello!

Dear Samba dev. team, is not this bug forgotten? :)

Thanks
Dmitry
Comment 23 Volker Lendecke 2011-07-28 14:07:25 UTC
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
Comment 24 TAKAHASHI Motonobu 2011-07-28 14:16:53 UTC
(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
Comment 25 Volker Lendecke 2011-07-28 14:23:44 UTC
Sorry, but in neither of those comments nor in the mailing list post I see

strict allocate = yes

in the sample smb.conf files.
Comment 26 TAKAHASHI Motonobu 2011-07-30 17:21:05 UTC
(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.
Comment 27 Volker Lendecke 2011-08-01 11:22:06 UTC
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.
Comment 28 Dmitry 2011-08-01 11:37:52 UTC
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
Comment 29 Volker Lendecke 2011-08-01 11:57:00 UTC
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.
Comment 30 Volker Lendecke 2011-08-01 11:58:13 UTC
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.
Comment 31 Volker Lendecke 2011-08-01 12:02:44 UTC
(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.
Comment 32 Dmitry 2011-08-01 12:20:52 UTC
My latest success test configuration was win7 server, winVista client, SMB2 protocol, FAT32.
In this test file not increased, all good.
Comment 33 Volker Lendecke 2011-08-02 13:52:13 UTC
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