NFS+Windows+UTF8 russian

Есть следующая проблема:

под linux(локаль ru utf8) настроен NFS сервер, который раздает шары для юзеров. С линуксовых машин все работает отлично, но в сети есть также пару виндовых(WinXP) машин(хвала налоговой, банкам и другим службам, которые пишут свои проги только под оффтоп). Так вот, проблема в следующем — при подключении NFS шар под винду (посредством SFU, пробовал также diskaccess и crossmeta-nfs) все русские названия показываются каракулями.

Если кто-нибудь встречался с подобным, буду рад советам как это вылечить.

Re: NFS+Windows+UTF8 russian

а почему бы самбу для расшаривания не юзать ?

Re: NFS+Windows+UTF8 russian

Тот остаток винд что у нас остался мы заставляем их юзать ftp к файлопомойке. Все клиенты NFS под винду которые пробовали, какието кривые и не совсем правильно работали.

Re: NFS+Windows+UTF8 russian

на счет самбы — надо будет попробовать, просто не хотелось кучу программ заводить для этого, но если не получится, то прийдется.

ftp к сожалению не очень подойдет для этого :(. им необходима групповая работа с файлами.

Re: NFS+Windows+UTF8 russian

> а почему бы самбу для расшаривания не юзать ?

Тормоз, ручной тормоз.

Re: NFS+Windows+UTF8 russian

NFSAXE под винду не пробовали? http://www.labf.com/nfsaxe/index.html (штука платная)

Re: NFS+Windows+UTF8 russian

NFSAxe — та же самая болезнь 🙂

Уже решил вопрос: samba с авторизацией в LDAP + ACL

Использование клиента NFS в Windows 10 редакции Professional

Администрируя серверы на базе ОС Linux в среде, где в качестве основной клиентской ОС используется Windows, время от времени приходится сталкиваться с необходимостью что-либо скопировать с клиентской Windows на Linux-систему или наоборот, с Linux-системы на Windows. Чаще всего для этого используются возможности протоколов SSH/SCP с помощью таких инструментов, как например, утилита pscp.exe. Но когда приходится сталкиваться с файловыми Linux-серверами, позволяющими использовать возможности протокола NFS, мы можем задаться вопросами типа «может ли клиентская ОС Windows выступать в качестве NFS-клиента?», «есть ли в клиентской ОС Windows какая-то встроенная реализация клиента NFS?». Именно такие вопросы у меня возникли в период времени, который совпал с периодом, когда мы перебирались с Windows 8.1 на первый релиз Windows 10. Информация, которую в тот момент удалось найти по этому вопросу, заключалась в том, что функциональность NFS-клиента имеют только «старшие» редакции клиентских ОС Windows, такие как Windows 7 Ultimate/Enterprise, Windows 8/8.1 Enterprise и Windows 10 Enterprise. Однако в нашем случае использовалась ОС Windows 10 редакции Professional, поэтому пришлось отбросить эти мысли.

Недавно, читая обсуждения на форумах TechNet, я столкнулся с информацией о том, что с какого-то момента времени в ОС Windows 10 редакции Professional появилась возможность использовать функционал NFS-клиента. По информации из некоторых источников такая возможность появилась в Windows 10 версии 1607 (10.0.14393 / Anniversary Update).

Решив проверить эту информацию на имеющейся у меня под руками Windows 10 1803 (10.0.17134 / April 2018 Update) редакции Professional, я обнаружил, что теперь у нас действительно имеется возможность использования этого функционала.

Чтобы включить NFS-клиента, можем воспользоваться оснасткой управления программами и компонентами appwiz.cpl. Здесь в перечне «компонентов Windows» можно найти доступные к включению «Службы для NFS«.

После завершения установки компонент в Панели управления в разделе «Администрирование» появится оснастка «Службы для NFS» (nfsmgmt.msc), в которой мы сможем управлять некоторым параметрами работы NFS-клиента.

Предполагаем, что на стороне NFS сервера уже настроены разрешения для доступа с клиентской системы, например, явно разрешён доступ по IP адресу клиента. Простейший пример установки и настройки NFS-сервера на стороне CentOS Linux можно найти в статье Вики «Установка и настройка сервера и клиента NFS в CentOS Linux 7.2».

После настройки прав доступа на стороне NFS-сервера переходим на Windows 10 и выполняем подключение сетевого каталога с помощью утилиты «mount«. Простейший пример анонимного подключения к сетевому каталогу выглядит так:

• «-o anon» — подключаться с правами анонимного пользователя;
• «KOM-FS01» — имя NFS-сервера;
• «mnt\vdo-vd1\ovirt-iso-domain» — локальный путь к каталогу на NFS-сервере;
• «I» — буква диска Windows

Другие доступные параметры и ключи утилиты, можно посмотреть командой «mount /?«. Например, при подключении мы явно можем указать имя пользователь и пароль на NFS-сервере.

При открытии свойств каталогов и файлов в подключённом NFS-каталоге мы увидим специальную вкладку «Атрибуты NFS» с соответствующими атрибутами, в том числе и информацию о текущих разрешениях на каталог/файл, которыми, в случае достаточных прав, мы можем управлять.

При повторном выполнении команды mount без указания параметров, мы получим сведения о текущий подключениях NFS-клиента и свойствах этих подключений:

Здесь мы сможем увидеть то, с какими UID и GUID, выполнено подключение. Для анонимных подключений это по умолчанию -2/-2. Если по какой-то причине у нас возникнет необходимость изменить эти идентификаторы для всех анонимных клиентских подключений, то мы можем добавить пару отсутствующих по умолчанию параметров реестра типа DWORD (32-бита):

В значениях созданных параметров можно записать нужные UID и GUID, которые будут использоваться при всех анонимных подключениях. На скриншоте ниже используется пример со значениями 1000:1000 (десятичное).

Если мы хотим, чтобы все анонимные подключения использовали root-овые идентификаторы, то в соответствующих параметрах реестра нужно указать AnonymousUid = 0 и AnonymousGid = 0. Указание root-овых идентификаторов может быть полезно в случае, если, например, нам требуется не только чтение, но запись в подключенном NFS-каталоге, а удалённый NFS-сервер разрешает запись только root-пользователю и/или членам группы root.

Для вступления изменений в силу потребуется выполнить остановку и повторный запуск службы клиента NFS из ранее упомянутой оснастки «Службы для NFS» (nfsmgmt.msc).

Либо, если перезапуск компьютера не составляет проблемы, то для вступления изменений в силу можно выполнить и перезагрузку клиентского компьютера.

Здесь хочу сделать маленькое отступление относительно перезапуска службы клиента NFS и поделиться своими наблюдениями.

Мои попытки перезапускать системную службу «Клиент для NFS» (NfsClnt) через стандартные механизмы, такие как оснастку управления службами services.msc или утилиту «net«, показали, что это по какой-то причине приводит к невозможности запуска службы после её остановки. Поэтому для перезапуска NFS-клиента лучше использовать именно «родную» оснастку. Хотя, опять же, замечено, что многократные остановки/запуски службы в оснастке «Службы для NFS» также могут привести к неадекватной работе NFS-клиента. В результате чего, например, утилита «mount» может перестать подключать NFS-каталоги, выдавая ошибку сети:

В таких случаях помогает только перезагрузка клиентского компьютера, после которой всё снова начинает работать.

После того, как нужные нам изменения внесены в реестр и служба клиента NFS успешно перезапущена, снова попытаемся подключить NFS-каталог и посмотрим командой «mount» сведения о подключениях.

Как видим, теперь в качестве идентификаторов безопасности выступают именно те, что были ранее нами указаны в реестре.

Отключение подключенных по протоколу NFS сетевых ресурсов выполняется также просто, как и подключение, только с помощью другой утилиты – «umount«

В общем это хорошо, что теперь у пользователей ОС Windows 10 редакции Professional есть штатная возможность работать с сетевыми файловыми ресурсами по протоколу NFS. Будем использовать это в работе.

Windows mount nfs utf8

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

For many years, UTF-8 has become the default encoding in the Unix world. However, even under WIndows Server 2012 RP, the `mount’ command to mount an NFS share from another machine still does only support the most basic SBCS and DBCS encodings.

Are there any plans to make the NFS client UTF-8 capable, and shouldn’t that be the default encoding nowadays anyway?

Thanks in advance,
Corinna

All replies

I’m going to contact develop department for this question before giving an answer. If there is any information about it I will post later.

TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

Sorry for the delay in reply.

Here is the information I got:

NFS v2/v3 RFCs don’t address this, v2/v3 are all ASCII only. On a side note, NFS V4.1 is UTF-8 mandated and we support that.

What NFS v2/v3 server are you using that needs this functionality on the Windows NFS client and can you give some details on the scenario?

• Edited by MedicalS Microsoft contingent staff Tuesday, June 12, 2012 8:47 AM

I think there’s a misconception. 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.

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

NFS share is mounted using mount server:/share x: command.
File(cyrillic) «Новый текстовый документ.txt» created with samba share (and using UTF-8) is shown as «РќРѕРІС‹Р№ текстовый документ.txt» under windows via NFS share.
How to make windows use UTF-8?

3 Answers 3

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

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).