We've got 4 ReadyNAS in operation. The 2 oldest units run RAIDiator: v4.1.16 with Samba v.3.6.25 and cannot be upgraded anymore.
Microsoft finally decided to dump SMBv1 and all machines on our network got upgraded to a life without SMBv1 hence the 2 old NAS were no longer available to the network. To resolve this issue we decided to enable NSF and disable SMB/CIFS. Microsoft was nice enough to include the NSF-Client and server in their updates. This way we can keep them units on the Network and in production as redundant backups of backups - we first thought. We we're able to map the shares to Windows 10, read and write data for testing, etc. all is operational.
So far so good and almost too nice to be true.
But there is a problem!
Folder- & file-names that use special characters changed their appearance. For instance all Umlaut like äöü became double characters. eg. the letter "ü" displays as double character "ü" in NSF-client. Yep it's an issue directly related to varying codepages.
Apparently the NAS OS (RAIDiator) uses varying codepages for SMB/CIFS and NSF.
The option for language selection in Frontview is missleading. To be on the safe side one would have to select english ASCII. By selecting any Unicode option incompatibility between SMB/CIFS and NFS filesystems/protocols gets in effect without any mention.
This is not documented by Neatgear (at least we could not find anyting).
We assume we're not the first and only customers experiencing this senselessness and would like to learn wether there is a solution that we might have missed.
Apparently the NAS OS (RAIDiator) uses varying codepages for SMB/CIFS and NSF.
Those language options apply to the web pages, not the file sharing protocols. In the specific case of NFS, NFSv2 and NFSv3 doesn't allow for character encoding - the assumption there is that the client and server have to match.
NFSv4 is supposed to use UTF-8, however that isn't enforced in the NFS clients. And I don't think your legacy NAS supports NFSv4.
I solved the filenaming / code-page problem with the following operations on Windows 10:
- copy & verify ALL content from the NAS to some newly formated disk(s). Copyied folders and files using robocopy.
- delete ALL content on the NAS
If you know what files are affected, you could probably just rename them from an NFS mount, which would of course be much faster.
It'd be pretty simple to write a script to identify files on the SMB mount that can't be found on the NFS mount. Not so easy to figure out the corresponding NFS file name.
Re: Character encoding, Codepages, SMB/CIFS and NFS
True. with the aid of a script, one would gain some time. In addition the risk-factor will raise. According to Murphy's law, all will look perfect only to find out that one or more critical file(s) was missed and that of course 3 years later.
In addition there is metadata in each file that MAY be affected as well - though I have not checked this factor.
Would be interesting to learn more about that. Check it out and post the results.
However, a time-consuming copy-process might still be the easiest and likely the safest.
After all my really old ReadyNas TL6 (made by Infrant) and ReadyNas NV+ are still serving its purpose in a Windows 10 environment as an NFS-Client. A pretty good example of real world effecitve sustainability.
