For the third time the disk in bay 4 of my Iomega StorCenter ix4-200d, failed, and finally the good folks at Iomega/Ems/Lenova sent me a brand new ix4-300d. As far as I can see it’s the same thing but with some bug fixes, more bling and a lot of cloud™.
I’ve been relying on rsync as the backbone of my backup solutions for years and so naturally I was going to use rsync to copy the data from the old nas box to my new one. So I set up the new NAS, then set up rsync in a screen session on my desktop and walked away.
The following day a quick comparison showed a 3GB difference between the source and destination. When I re-ran the rsync, I was suddenly faced with loads of error messages from the un-synced files that I had not noticed before.
rsync: mkstemp “/new/path/to/files/some:file.txt” failed: No such file or directory (2)
Searches on the web threw up information which to be honest didn’t help a lot and didn’t give a concrete explanation for what is going wrong. So left to my own I decided that the problem probably wasn’t rsync and that it was trying to tell me what was wrong. The searches on the internet suggested that the issue was related to file/directory permissions. I confirmed that this wasn’t the case and was able to create files on the old and new nas without problem. These files were even synced when I reran rsync.
So then the problem must be the files themselves. This was worrying as this meant that 3G of my files may be corrupt but keeping a cool head I had a look at the files themselves and then it hit me. All the file names contained characters outside the nice clean [0-9A-Za-z] range, and then I had a look at the type of mount and I noticed the source (old nas) is mounted over NFS while the destination (new nas) is mounted over CIFS. Looking at the list of error files, it became obvious that all the files contained reserved characters that are not acceptable on CIFS/Windows file systems. So the simple solution was to disable the default CIFS share and setup NFS shares and use those. Sure enough a few minutes later rsync was copying the files without issue.
The moral of the story is “read the screen” the only problem is that sometimes it’s difficult to interpret what it’s saying. So instead of focusing on No such file or directory (2), I needed to look at rsync: mkstemp “/new/path/to/files/some:file:with:colon:in:the:name.txt” failed: and ask why is it failing.