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

[Harrison]

Mathieu,

I am currently using Windows 10 Pro x64 (1511).  I plan on upgrading to
(1809) or (1903) in the next month.  If it would be help in diagnosing
this problem, I can do it this week.

What concerns me the most about this problem is that when I use CIFS on
the Debian side, everything works correctly.  But, when I use SAMBA from
the Windows side, the "available space" in the root partition is used,
instead of the non-backed partition where the Folder to which I am
copying is located, when I SMB "connect" to root.  But, if I SMB
"connect" to the Sub-Folder in the non-backed partition, everything
WORKS correctly!  The symptoms suggest to me that the problem is the
SAMBA code that initially sets up the copy is not obtaining the
"available space" for the correct partition, non-backed.

Oh, and just yesterday, an immense number of SAMBA updates appeared and
I installed them.  If there was anything in Samba 2:4.5.16+dfsg-1 that
might address this problem, I don't mind testing again.  The
folders/files that I am copying in one operation are in the 50-100 GB
range.  But, there is more than an adequate amount of "available space"
in the partition.  Here is the "df -h" output:

Filesystem              Size  Used Avail Use% Mounted on
udev                     16G     0   16G   0% /dev
tmpfs                   3.2G  9.7M  3.2G   1% /run
/dev/mapper/sda3_crypt   59G  9.6G   46G  18% /
tmpfs                    16G     0   16G   0% /dev/shm
tmpfs                   5.0M  4.0K  5.0M   1% /run/lock
tmpfs                    16G     0   16G   0% /sys/fs/cgroup
/dev/sdb1               3.6T  3.1T  333G  91% /mnt/Non-Backed
/dev/sda6               236M   64M  160M  29% /boot
/dev/sda1               487M  132K  486M   1% /boot/efi
/dev/mapper/data        234G   11G  212G   5% /mnt/data
tmpfs                   3.2G   16K  3.2G   1% /run/user/116
tmpfs                   3.2G   40K  3.2G   1% /run/user/1000

Harrison


On 2/18/2019 3:04 AM, Mathieu Parent wrote:
> Please keep the bug CC-ed.
>
>
> Le sam. 16 févr. 2019 à 18:32, Harrison
> <sainokawara.sisyphus at gmail.com> a écrit :
>> Mathieu,
>>
>> 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.
> Because your file is > 1000MB?
>
>> 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?
> You said that you are using Windows 10. Is this the 32bit or the 64bit version?
>
>
> Please provide your smb.conf, df -h output.
>
> Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-samba-maint/attachments/20190218/175f813f/attachment.html>