O compartilhamento NFS é montado usando o comando mount server:/share x: .
Arquivo (cirílico) "Новый текстовый документ.txt" criado com compartilhamento de samba (e usando UTF-8) é mostrado como "РќРѕС Р№ тксттРТРСРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРРАСТВ" br>
Como fazer o windows usar o UTF-8?
Você pode usar o fuse-convmvfs: monte sua pasta do servidor por fuse-convmvfs (input charset - utf8, output - cp1251) e configure o nfsd para usar o FS convertido
exemplo:
> 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)
Não há como resolver seu problema sob essa configuração, nem mesmo o método fornecido na "Resposta correta" desta pergunta. Isso não é um erro, é por design para criar a barreira que você está enfrentando. Não é possível que o designer do NFS Client ofereça a opção de usar o BIG5, EUC-KR, EUC-JP, ksc5601, GB18030, SHIFT-JIS e simplesmente esqueça UTF-8 e continue esquecendo de remendá-lo up em uma década . Todos esses códigos são usados por várias versões do Windows, exceto UTF-8, não por coincidência. Na verdade, a intenção da Microsoft é de brigar com UNIX e Windows antigos, para promover a migração do Unix para o Windows, e deve-se medir com cautela que isso não dá ao seu concorrente Linux um ambiente fácil de existir. Qualquer recurso que torne o Linux diferente do Unix ou do Unix moderno diferente do antigo-unix-a-ser-substituído será excluído. É precisão no marketing, trabalho bem feito.
Deixe-me mostrar como todas as formas estão bloqueadas:
A idéia é encontrar algum software que possa transcodificar dinamicamente nomes de arquivos, por exemplo, inserindo-se uma camada entre o FS e o SO. Ou, encontre algum software que possa configurar um ambiente para que outro software use esse sistema de arquivos. Nenhum software conhecido do Windows pode fazer isso. Isso não funciona, porque ao contrário do Linux, que permite que cada aplicativo use uma codificação diferente, o Windows configura uma codificação para um FILESYSTEM.
A maioria dos servidores NFS é Linux. Em teoria, pode-se usar fuse-convmvfs para criar um espelho do sistema de arquivos e exportá-lo. Oleg Lobach demonstrou o código para fazer isso, e está marcado como correto sem teste. Não funciona porque o servidor NFS do Linux só pode exportar o sistema de arquivos FUSE no NFSv4, não no NFSv2 / v3, entretanto, o Windows 7 (assim como o Serviços para Unix v3.5) suportam apenas o NFSv2 / v3, não o NFSv4. Eu demonstrei esta limitação em detalhes em outra resposta.
O problema é elaborado em 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.
A melhor solução é, obviamente, abandonar o Windows. Não é importante hoje em dia, e a tendência global não é mais liberar o software somente do Windows. Se você estiver preso a aplicativos antigos do Windows, poderá alterar seus requisitos:
Alternar cliente NFSv2 / v3: você pode instalar o driver de montagem land-user do Windows para o Windows, depois a unidade Neko NFS, que mapeia o NFS para um driver de dispositivo com a opção "Unicode". Clique nessa opção para fazer o UTF8 funcionar. Suporta NFSv2 e v3, mas não v4. Ele não suporta link simbólico ainda (como o cliente da Microsoft faz).
Cliente Siwtch NFSv4: você pode deixar o cliente NFS embutido para o livre A implementação de referência do NFS 4.1 para Windows pelo UMICH CITI , embora difícil de instalar, deve elimi- nar o problema (porque o NFS4 requer explicitamente o UTF-8) ou possibilitar o uso da solução de fusível-referência acima mencionada.
Switch OS: o Windows Server 2012 adicionou suporte ao servidor NFS 4.1, portanto há uma chance de incluir um cliente NFS 4.1 também.
Ambos os switches não funcionariam se o seu servidor suportasse apenas o NFSv3, por exemplo, se você usa o OpenWRT (mesmo a versão mais recente do servidor OpenWRT ainda não pode fazer o NFSv4).
Eu só queria observar que tentei o cliente UMICH CITI NFS, mas me deparei com problemas de inicialização segura.
Ao tentar executar:
bcdedit /set testsigning on
conforme instruído pelas instruções, recebi o seguinte erro:
An error has occurred setting the element data.
The value is protected by Secure Boot policy and cannot be modified or deleted.
Portanto, a menos que você queira mexer com suas configurações de inicialização segura, não é recomendável tentar usar o cliente CITI.
A solução ideal para isso seria o CITI assinar o driver para que ele possa ser usado sem o modo de teste. Mas considerando que é bem antigo, não acho que isso vai acontecer.