"rsync: [generator] mknod … failed: File name too long (36)" though file & path name lengths are way shorter than 255 & 4096

On a QNAP NAS I'm trying to copy a huge backup directory from internal to an USB disk. The backup set was created using back-in-time, therefore it uses hard-links for deduplication and encfs generated file & directory names.

Running rsync -aH --inplace /share/MD0_DATA/Backups/ /mnt/t2/B/ I receive the following errors:

rsync 3.0.7 (QNap stock)

sync: mknod "/mnt/t2/B/home/8QxnYj…iE0pCkQxr" failed: No such file or directory (2)

rsync 3.2.7-1a (Entware)

rsync: [generator] mknod "/mnt/t2/B/home/8Qxn…iE0pCkQxr.26280" failed: File name too long (36)

Not the usual 255/4096 filename length limitation

I'm aware of the 255 bytes filename length and 4096 bytes pathname limit: But this doesn't seem to apply here in my case.

• The longest single file/directory name is only 47 characters
• The full path is only 294 characters long
• The source path is even longer!
• The source files were even created by back-in-time using the same local rsync as receiver. It's just a different server a sender.
• I can easily create and delete the exact paths using touch and rm
• Source and target are on the same system, same filesystem type (ext4), having identical mount options.

I.e., one sample path rsync reports reads: /mnt/t2/B/home/8QxnYjsi5RSEftKDx9qGbzq3/l7ZyYNV0C,yeUTgnIuhcEQBb/ayR8ehutEqbvovJLf36EYUH1/qeJqrGaptTSMwTPoezYN2mTb/-P-gLqJGmcDYgYp6GXsLX1uaucCW-nRUlhftGIeeRotg70/vBksKzx1a3G0lIbOPqKeJEe1/Er1HTeysXU8ENmZfYkbsAPCl/XyR8ehutEqbvovJLf36EYUH1/LzHu4oEpUPIXMypAwK5XGU7L/.y-gLkcg40i8ooEbiE0pCkQxr.26280

Any ideas on the culprit and how to solve this?

At the end it turned out that both error messages are just misleading: The source file seems to be a set of backed up socket files. Only those files produced those errors.

srwxrwxr-x    1 ben      ben              0 Jul  4  2021 y-gLkcg40i8ooEbiE0pCkQxr

Interestingly the claimed target filename is .y-gLkcg40i8ooEbiE0pCkQxr.26280, while the actual source file misses source and prefix and is actually y-gLkcg40i8ooEbiE0pCkQxr (without the leading dot and the trailing number).