NAS 326 TRANSFER ERROR VIA FTP: TOO MANY OPEN FILES

This is really weird as I tested with different client and upload 13,000 photos, then never see the problem. What is your firmware version? Not sure if there is any configuration to cause the problem occurrd...wait for your update for Macbook.

Normally if you make the reset (3bip), it only reset the configuration without lost data

Hi, I have the same issue on  Zyxel NAS542;
I believe the root cause is the "open files limit"  witch is set to 1024. (login to Zyxel NAS with SSH terminal, and type 'ulimit -n').  You could try to set a higher limit, but it doesn't 'stick' (after logout/reset it reverts back to 1024).

So, if you want to transfer a lot of SMALL files (like 1300 photos) you could:

1) setup a batch transfer like 100 files/pause for 10 seconds/next 100 files...etc
2) set a limit on transfer rate (i'm transfering 18073 small files at 1500kbit/sec= 1.5Mbit.sec)...it will take a while....
3) Make storage-only big archive with all the small files, and transfer that single archive (!Dangerous! - if the big archive is corrupted, you could loose your files)

@Zyxel Team:
      - Please make a firmware update so we can increase the kernel limit of "open files" via SSH
     or just set it to a higher number like '20000' (ulimit -Hn 20000   |   ulimit -Sn 20000 )

That limit shouldn't be there, and most people are not affected. If increasing the open file limit solves the problem, than it's a work-around, not a solution of the lower problem.

It makes no sense to upload more than, let's say, 10 files simultaneously, because the disk(s) can't handle that. If a mechanical disk has to store several streams simultaneously, the throughput decreases dramatically.

So any decent FTP client won't open more than 10 streams by default.

Each stream causes 5 open file handles on the server. One for the actual file being written, and one for the TCP/IP socket. (On FTP each stream has it's own TCP/IP connection). Futher each stream has it's own process spawned, with an open stdin, stdout and stderr (all to /dev/null).
So when using 10 streams, there should be 50 open files for the streams, plus 4 for the 'main process' (listening socket on port 21, and stdin, stdout and stderr)

In your case I suspect a network problem, which prevents the sockets from being closed. Which means. That could be a driver problem on the client side, maybe a buggy checksum offload.

Does your Mac expose the same problem?

@cozmin: If you install the Tweaks package you can use the cron applet to set your limits @reboot.