[Pkg-samba-maint] Bug#878163: Fwd: Bug#878163: samba: Samba updates from Windows 10 fail because "Size on Disk" miscalculated

Mathieu Parent math.parent at gmail.com
Mon Feb 18 10:53:02 GMT 2019


please cc to the bug. Forwarding it below.

---------- Forwarded message ---------
From: Harrison <sainokawara.sisyphus at gmail.com>
Date: sam. 16 févr. 2019 à 18:32
Subject: Re: [Pkg-samba-maint] Bug#878163: samba: Samba updates from
Windows 10 fail because "Size on Disk" miscalculated
To: Mathieu Parent <math.parent at gmail.com>


Upon rereading my reply to you, I noticed that I wasn't crystal clear
in explaining the test results when I "selected the /mnt/non-backed
folder" in the "Map network drive" function in Windows Explorer.  When
I tested this with "max disk size = 1000", the copy was not even
attempted due to lack of space as I indicated.  HOWEVER, when I tried
this with "max disk size = 1000000", the copy was initiated and was
successful.  I hope these two results are consistent with your
understand of how the code works and the "max disk space = 1000"
option?  It would seem that this option "overrode" the actual "free
space" on the "non-backed" partition which was more than adequate to
hold the data being copied?


Below is the prior email I sent you:

On 2/16/2019 7:44 AM, Harrison wrote:


Interesting option, I loved the comments in MAN on it!  Unfortunately,
the Windows Explorer "copy function" using SMB refused to even try
telling me that "Space Free:  999 MB" and "Total Size: 0.97 GB" which
would be consist with "max disk size = 1000".   So, I tried setting
"max disk size = 1000000" and tried again.  It again refused to try
the "copy" telling me:  "Space Free:  37.5 GB" and "Total Size:  58.4
GB".  Apparently, you can only "lie" to SAMBA so much!  I also tried
selecting the "/mnt/non-backed" folder in the "Map network drive" but
SAMBA knows that is the "root" partition even though the "non-backed"
partition is mounted on it.

I am comfortable with the "workaround" of "selecting a sub-folder in
the actual partition where the data will be copied on the Map network
drive" although this is less than ideal for general users.  I have not
checked any of the Debian code and haven't a clue what Windows
Explorer sends to SAMBA when it is checking for adequate space before
initiating a copy.  But, unless this initial request identifies the
actual "folder" in which the data is to be stored, there is no
solution.  If it does identify the "folder", SAMBA would have to
"walk" the directory tree towards "root" looking for the partition in
which the data would be stored and send back the correct "space
information" for the partition to Windows Explorer, or whoever is
making the request.  I suspect there is enough information on the
request and that it is doable so it all comes down to need and

If SAMBA is like any other software group, there are more requirements
than resources to do all of the work.  I did check and see that you
are listed as a "maintainer" and might know.  Under some
circumstances, there might be additional resources to get this done if
it were deemed important enough to even do.  Let me know if anyone is
interested in pursuing this option.


On 2/15/2019 10:55 PM, Mathieu Parent wrote:

Hello Harrison,

Try setting in smb.conf:

max disk size = 1000

Le vendredi 15 février 2019, Harrison <sainokawara.sisyphus at gmail.com> a écrit :
> Louis,
> My apologies, I never received your email.  My email provider is a little too aggressive about "protecting" me from spammers.  After reading your reply to my "bug report", everything is "explained" but Debian does have some bugs, plural.
> My Debian system consists of several partitions, the two relevant ones here are "root" and "non-backed".  My "root" partition, containing only the OS, is only 64 GB; the "non-backed" partition is mounted on /mnt/non-backed and is 4 TBs.
> When I "display" the attributes of "non-backed", I get slightly different, but consistent, values depending upon whether I use "Disks" or "Nautilus" on the Debian side or "Windows Explorer" on the Windows side.  But, what really caught my attention was the "total space" reported when an SMB "copy" failed [wasn't attempted due to space] from the Windows side:  "total space:  64 GB"!  It appears that the "Windows Explorer" copy function using SMB is "checking" the "available space" in the "root" partition and not the "available space" in the "non-backed" partition mounted on /mnt/non-backed prior to doing the copy and just failing the copy!  Not knowing enough about the various components involved, I don't know which component would "own" any bug.
> When I tried your suggestion of SMB "mounting" one of the sub-folders in the "non-backed" partition instead of the "root" partition, EVERYTHING WORKED!  I did see a potential "cosmetic" bug in "Disks" but that would be a completely different issue.  I don't know how/where it obtains the information, but it reported that the "non-backed" partition was mounted on /media/Music instead of /mnt/non-backed.  Actually, one of the sub-folders in "non-backed" is mounted on /media/Music and another on /media/Videos so it may just be displaying the "wrong" one instead of /mnt/non-backed?
> Harrison
> I hope you don't get multiple copies of this.  I encountered several minor "glitches" trying to send it to you.  If you do, my apologies.



More information about the Pkg-samba-maint mailing list