I am running windows 11 on my server and the target for the backup is a share on my NAS WD-EX4100
This error is now popping up
Is this just something that is the way it is? or can I change a setting on the NAS to fix it?
Thank you
George
(err_long_create_failed). The filename, directory name, or volume label syntax is incorrect. (code: 123)
UrBackup Server has trouble storing files to backup storage with the maximum file name length it was compiled with (255 UCS-2 code points/UTF-16 with max 2*255 bytes). There might be issues when backing up files/folders with long file name.
I’m still seeing the same thing on the UrBackup web UI when I log in as administrator. I don’t recall seeing this before, though. This just popped up in the last few months (maybe after I migrated my server jail to a new host).
The only difference here is I’m backing up FreeBSD and Linux systems to a FreeBSD 15.1-RELEASE host running UrBackup Server. The error I see is:
“(err_long_create_failed). No such file or directory (code: 2)
UrBackup Server has trouble storing files to backup storage with the maximum file name length it was compiled with (max 255 bytes). There might be issues when backing up files/folders with long file name.”
Looking through the forums here, it seems this question has come up many different times in many different aspects and on many different systems without any solution (or even replies, really?). So, not certain what should be done here. Backups all seem to work fine?
I take this back. I did see a reply saying the error was misleading and it was due to file permission issues. I’ve changed the permissions on the top-level directory to be owned by the urbackup user and group and will see if this resolves the issue. It’s hard to tell since I only see the error every once in a while.
I can reproduce this on Linux with 2.5.x, and it isn’t about file name length or permissions. Every time the Status page loads, the server runs its storage checks inside a test folder with a fixed name in the backup folder. If two of those checks overlap (two browser tabs, two admins, a quick reload), one removes the folder while the other is still using it, and the second one reports “No such file or directory (code: 2)” as err_long_create_failed.
In a test, 200 status checks one after another gave no errors, while four parallel loops gave about 15% spurious errors, including this exact one. Serializing the checks made them go away.
So if it only shows up now and then, disappears on reload, and backups work, it is harmless and your storage is fine. Changing ownership shouldn’t be needed. If it showed every time, that would be a real storage problem.
(The original post with code 123 on Windows is a different case. There the NAS share really does reject the long name.)
OPs issue is just a limitation. The only option there might be to accept & ignore this and not complain if there is a filename with e.g. cyrillic characters that takes up more than 255 bytes and backups fail (unlikely though).
@eekay35 If your issue is caused by simultaneous calls to the check function, then @LJ_LongWing 's change will fix it.
Thank you both very much for this info! I’ll keep an eye on it and see what happens. I don’t think I’ve ever had more than one connect to the admin interface, but quick refresh/reloads makes perfect sense in this scenario. Thanks again!