I mean... for me problem solved, but below I report my test.
The test environment is OMV3 installed under Virtualbox.
OMV3 is updated to the latest version 3.0.81. There are 3x1GB Virtual HD formatted in EXT4 and correctly mounted, labeled one, two, three.
Active services: NFS, SAMBA, SSH and FTP with default parameters.
MergerFS V. 2.22.1 is the only installed & activated plugin.
Through mergerfs plugin I created a pool called myufs with the following options:
Name: myufs
HDs: one + two + three
Create Policy: LFS
Minimum Free Space: 50M
Options: defaults,allow_other,direct_io,use_ino,moveonenospc=true
Within myufs pool I created a shared folder called myshare:
The only user in OMV (myusr) has all the privileges on the share.
I finally added the shared folder as share to NFS, SAMBA, and FTP services.
To test the environment I created three files of 450MB (dd if = / dev / zero of = testfilex.dat bs = 1M count = 450) on my local machine, which I then copied using the various protocols / services in the shared folder on pool created by MergerFS.
-rw-r--r-- 1 rbnet rbnet 471859200 juin 28 10:26 testfile1.dat
-rw-r--r-- 1 rbnet rbnet 471859200 juin 28 10:26 testfile2.dat
-rw-r--r-- 1 rbnet rbnet 471859200 juin 28 10:26 testfile3.dat
Through samba, nfs and scp I then copied one file at a time into the share using the various services.
The first file (testfile1.dat) goes always on the HD labeled, three, second file (testfile2.dat) goes on the same HD, as previous settings (policy LFS).
With the second file copied on HD, the free space in the HD is 70MB.
When I start copying the third file (testfile3.dat), initially it is copied in the HD three because of free space 70MB > minfreespace 50MB. When the HD is filled the file is moved to a HD (labeled one in this case) with enough space to hold it. This is when moveonenospc is triggered, right?
For simplicity I have captured the intial copy on the HD three and the next "move" of the file on HD one using the Filesystem Status of OMV AdminCP:
The initial state (before copying the 3rd file):
This is exactly the behaviour for all file transfer with SAMBA, NFS, SCP and (locally) for the cp/mv commands. And it is correct.
With FTP, instead, I have obtained errors about a broken PIPE, regardless the client used, when I copy the third file (same environment as above, obviously). This is a log of Filezilla when the error is triggered during the upload of testfile3.dat:
15:02:32 Status: Starting upload of /home/rbnet/Scaricati/testfile3.dat
15:02:36 Command: CWD /myshare
15:02:36 Response: 250 CWD command successful
15:02:36 Command: TYPE I
15:02:36 Response: 200 Type set to I
15:02:36 Command: PASV
15:02:36 Response: 227 Entering Passive Mode (192,168,1,44,148,95).
15:02:36 Command: STOR testfile3.dat
15:02:36 Response: 150 Opening BINARY mode data connection for testfile3.dat
15:02:36 Response: 451 Transfer aborted. Input/output error
15:02:36 Error: File transfer failed after transferring 76.0 MB in 4 seconds
15:02:36 Status: Starting upload of /home/rbnet/Scaricati/testfile3.dat
15:02:36 Status: Retrieving directory listing of "/myshare"...
15:02:36 Command: PASV
15:02:36 Response: 227 Entering Passive Mode (192,168,1,44,174,71).
15:02:36 Command: MLSD
15:02:36 Response: 150 Opening BINARY mode data connection for MLSD
15:02:36 Response: 226 Transfer complete
15:02:36 Command: PASV
15:02:36 Response: 227 Entering Passive Mode (192,168,1,44,145,237).
15:02:36 Command: REST 75878400
15:02:36 Response: 350 Restarting at 75878400. Send STORE or RETRIEVE to initiate transfer
15:02:36 Command: STOR testfile3.dat
15:02:36 Response: 451 testfile3.dat: Append/Restart not permitted, try again
15:02:36 Error: File transfer failed after transferring 0 B in 1 second
15:02:36 Status: Starting upload of /home/rbnet/Scaricati/testfile3.dat
Alles anzeigen
Same things with FTP via Shell (or any other FTP client):
ftp> put testfile1.dat
local: testfile1.dat remote: testfile1.dat
200 PORT command successful
150 Opening BINARY mode data connection for testfile1.dat
226 Transfer complete
471859200 bytes sent in 1.34 secs (336.8009 MB/s)
ftp> put testfile2.dat
local: testfile2.dat remote: testfile2.dat
200 PORT command successful
150 Opening BINARY mode data connection for testfile2.dat
226 Transfer complete
471859200 bytes sent in 1.50 secs (299.2429 MB/s)
ftp> put testfile3.dat
local: testfile3.dat remote: testfile3.dat
200 PORT command successful
150 Opening BINARY mode data connection for testfile3.dat
netout: Broken pipe
451 Transfer aborted. Input/output error
Alles anzeigen
Then I discovered that is necessary to enable the option "Resume - Allow clients to resume interrupted uploads and downloads" on the OMV FTP options to avoid the error with FTP and the moveonenospc=true option
Now, If I repeat the same steps of uploading the three file, the error about the broken pipe on the third file is handled by the FTP client (if it can resume the interrupted uploads) that can automatically resume and finish the upload of the file in the new HD.
Simply this.
For me problem solved.
Thank you.