<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Mathieu,</p>
<p>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.</p>
<p>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.</p>
<p>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:</p>
<p>Filesystem Size Used Avail Use% Mounted on<br>
udev 16G 0 16G 0% /dev<br>
tmpfs 3.2G 9.7M 3.2G 1% /run<br>
/dev/mapper/sda3_crypt 59G 9.6G 46G 18% /<br>
tmpfs 16G 0 16G 0% /dev/shm<br>
tmpfs 5.0M 4.0K 5.0M 1% /run/lock<br>
tmpfs 16G 0 16G 0% /sys/fs/cgroup<br>
/dev/sdb1 3.6T 3.1T 333G 91% /mnt/Non-Backed<br>
/dev/sda6 236M 64M 160M 29% /boot<br>
/dev/sda1 487M 132K 486M 1% /boot/efi<br>
/dev/mapper/data 234G 11G 212G 5% /mnt/data<br>
tmpfs 3.2G 16K 3.2G 1% /run/user/116<br>
tmpfs 3.2G 40K 3.2G 1% /run/user/1000<br>
</p>
<p>Harrison<br>
</p>
<br>
<div class="moz-cite-prefix">On 2/18/2019 3:04 AM, Mathieu Parent
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFX5sbwOJng1pHTUq_Q_jMBpnjBXs6M=TdLdCUpgASf32OCiHA@mail.gmail.com">
<pre wrap="">Please keep the bug CC-ed.
Le sam. 16 févr. 2019 à 18:32, Harrison
<a class="moz-txt-link-rfc2396E" href="mailto:sainokawara.sisyphus@gmail.com"><sainokawara.sisyphus@gmail.com></a> a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
Because your file is > 1000MB?
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<br>
</body>
</html>