What to do with NFS server (UTF-8) and Windows 7?

You can use fuse-convmvfs: mount your server folder by fuse-convmvfs (input charset - utf8, output - cp1251) and configure nfsd to use converted FS

example:

> convmvfs /mnt/converted-folder -o srcdir=/path/to/source/foleder, icharset=utf8,ocharset=cp1251

> vi /etc/exports
/mnt/converted-folder 192.168.1.*(rw,sync)

There is no solution with Microsoft's NFS client in Windows 7

There are no way to solve your problem under this setting, not even the method given in the "Correct Answer" of this question. This is not a mistake, it is by design to create the barrier you are facing. It is not possible that the designer of NFS Client offer the option to use BIG5, EUC-KR, EUC-JP, ksc5601, GB18030, SHIFT-JIS and simply forget UTF-8 and keep forgetting patching it up in a decade. All these codings are used by various versions of Windows except UTF-8, not a coincidence. In fact, Microsoft's intents to briget old UNIX and Windows, to foster migration from Unix to Windows, and it must be carefully measured that this does not give its competitor Linux an easy environment to exist. Any feature makes Linux different from Unix or modern Unix different from old-unix-to-be-replaced are excluded. It's precision in marketing, job well done.

Let me show you how every way is blocked:

To workaround the client side is no go:

Idea is to find some software that can dynamically transcode file names, for example by inserting itself a layer between FS and the OS. Or, find some software that can setup an environment for another software to use that file system. No known Windows software can do this. This does not work, because unlike Linux that allows each application to use a different encoding, Windows configure an encoding for a FILESYSTEM.

To workaround the server is no go:

Most NFS servers are Linux. In theory one could use fuse-convmvfs to make a mirror of the filesystem and export that. Oleg Lobach demonstrated the code to do this, and it is marked correct without test. It doesn't work because Linux's NFS server can only export FUSE file system in NFSv4, not in NFSv2/v3, in the meantime, Windows 7 (as well as Services for Unix v3.5) only support NFSv2/v3, not NFSv4. I demonstrated this limitation in detail in another answer.

The problem is elaborated in TechNet:

A POSIX filename is not ASCII but a stream of bytes. The same goes for filenames on NFS filesystems. The interpretation of the byte stream as a filename in a certain codeset is left as an excercise to the client application. If the filename byte stream represents a valid UTF-8 string, but the client application has set the codeset to, say, ISO-8859-5, any problem is the fault of the application. But we're talking about Windows. On Windows, the interpretation of a filename is not left to the application. Rather, the filename byte stream sent from the NFS server to the Windows client machine has to be converted to a UTF-16 string to be digestible by the OS. Therefore the interpretation of the filename byte stream has to be performed by the NFS client service, on a per mount point basis. The application has no say in it. And here's the problem. If the remote codeset used to create filenames is UTF-8, as is the default for many years in the POSIX world, there's no chance to get a correct filename from the Windows application point of view, because the interpretation of the filename is already done by the Windows NFS client which doesn't allow the conversion from UTF-8 to UTF-16. In fact, the NFS client only supports a restricted number of codeset conversions to UTF-16, all of them rather old-fashioned. This is not just a specific scenario. You have this problem in all scenarios in which you're accessing NFS shares on machines set to use MBCS like UTF-8 or GB-18030 from Windows NFS clients.

There are solutions if you opt for a switch:

The best solution is of course abandon Windows. It is not important nowadays, and the global trend is no longer to release Windows-only software. If you are stuck with old Windows applications, you can change your requirement:

• Switch NFSv2/v3 Client: you can install dokan user-land mount driver for Windows, then Neko NFS drive, which maps NFS to a device driver with an option "Unicode". Click that option to get UTF8 working. It supports NFSv2 and v3, but not v4. It doesn't support symbolic link yet (as Microsoft's client do).

• Siwtch NFSv4 Client: you can leave the in-built NFS Client for the free reference implementation of NFS 4.1 for Windows by UMICH CITI, although difficult to install, should either elimitate the problem (because NFS4 explicitly requires UTF-8) or made it possible to use workaround fuse-convmv mentioned above.

• Switch OS: Windows Server 2012 added support for NFS 4.1 server, so there is a chance that they included an NFS 4.1 client too.

Both switches would not work if your server only support NFSv3, for example, if you use OpenWRT (even the latest version of OpenWRT server still cannot do NFSv4).