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. Будем использовать это в работе.

Что делать с NFS-сервером (UTF-8) и Windows 7?

Общий ресурс NFS монтируется с помощью команды mount server:/share x:
Файл (кириллица) «Новый текстовый документ.txt», созданный с помощью общего ресурса samba (и использующего UTF-8), отображается как «РќРѕРІС‹ Р№ С‚РµРєСЃС‚РѕРІС ‹Р№РґРѕРєСѓРјРµРЅС‚.txt» в Windows через общий ресурс NFS.
Как заставить Windows использовать UTF-8?

3 ответа 3

Вы можете использовать fuse-convmvfs: смонтировать папку на сервере с помощью fuse-convmvfs (входная кодировка — utf8, выходной — cp1251) и настроить nfsd для использования преобразованной FS

Нет решения с NFS-клиентом Microsoft в Windows 7

В этом случае нет способа решить вашу проблему, даже метод, указанный в «Правильном ответе» на этот вопрос. Это не ошибка, это задумано, чтобы создать барьер, с которым вы сталкиваетесь. Невозможно, чтобы разработчик NFS Client предложил вариант использования BIG5, EUC-KR, EUC-JP, ksc5601, GB18030, SHIFT-JIS и просто забыл UTF-8 и продолжал забывать исправлять его в течение десятилетия. Все эти кодировки используются различными версиями Windows, кроме UTF-8, что не случайно. Фактически, Microsoft намерена создать старую версию UNIX и Windows, чтобы ускорить миграцию с Unix на Windows, и необходимо тщательно измерить, что это не дает конкурентной Linux простой среды для существования. Любые функции, отличающие Linux от Unix, или современные Unix, отличные от старых, которые должны быть заменены, исключаются. Это точность в маркетинге, хорошо выполненная работа.

Позвольте мне показать вам, как заблокированы все пути:

Чтобы обойти клиентскую сторону не пойдет:

Идея состоит в том, чтобы найти программное обеспечение, которое может динамически перекодировать имена файлов, например, вставляя себе слой между FS и ОС. Или найдите программное обеспечение, которое может настроить среду для другого программного обеспечения для использования этой файловой системы. Никакое известное программное обеспечение Windows не может сделать это. Это не работает, потому что в отличие от Linux, который позволяет каждому приложению использовать различную кодировку, Windows настраивает кодировку для FILESYSTEM.

Для обхода сервера нет пути:

Большинство серверов NFS являются Linux. Теоретически можно использовать fuse-convmvfs, чтобы создать зеркало файловой системы и экспортировать его. Олег Лобач продемонстрировал код для этого, и он помечен как корректный без теста. Это не работает, потому что NFS-сервер Linux может экспортировать файловую систему FUSE только в NFSv4, а не в NFSv2/v3, в то же время Windows 7 (а также Services for Unix v3.5) поддерживают только NFSv2/v3, но не NFSv4. Я продемонстрировал это ограничение подробно в другом ответе.

Проблема разработана в TechNet:

Имя файла POSIX — это не ASCII, а поток байтов. То же самое касается имен файлов в файловых системах NFS. Интерпретация байтового потока как имени файла в определенном наборе кодов оставляется в качестве упражнения для клиентского приложения. Если поток байтов имени файла представляет собой допустимую строку UTF-8, но клиентское приложение установило кодовый набор, скажем, ISO-8859-5, любая проблема связана с ошибкой приложения. Но мы говорим о Windows. В Windows интерпретация имени файла не предоставляется приложению. Скорее, байтовый поток с именем файла, отправляемый с сервера NFS на клиентский компьютер Windows, должен быть преобразован в строку UTF-16, чтобы ОС могла его переваривать. Поэтому интерпретация байтового потока имени файла должна выполняться клиентской службой NFS для каждой точки монтирования. Приложение не имеет права голоса. И вот проблема. Если для создания имен файлов используется удаленный кодовый набор UTF-8, как это делается по умолчанию в течение многих лет в мире POSIX, то нет шансов получить правильное имя файла с точки зрения приложения Windows, поскольку интерпретация имени файла уже сделана клиентом Windows NFS, который не позволяет преобразование из UTF-8 в UTF-16. Фактически, клиент NFS поддерживает только ограниченное число преобразований кодового набора в UTF-16, причем все они довольно старомодны. Это не просто конкретный сценарий. Эта проблема возникает во всех сценариях, в которых вы обращаетесь к общим ресурсам NFS на компьютерах, настроенных на использование MBCS, таких как UTF-8 или GB-18030, из клиентов Windows NFS.

Есть решения, если вы выберете переключатель:

Лучшее решение, конечно, отказаться от Windows. Это не важно в наше время, и глобальная тенденция больше не выпускает программное обеспечение только для Windows. Если вы застряли в старых приложениях Windows, вы можете изменить свое требование:

Переключение клиента NFSv2/v3: вы можете установить dokan user-land mount driver для Windows, затем Neko NFS drive, который сопоставляет NFS с драйвером устройства с опцией «Unicode». Нажмите эту опцию, чтобы заставить работать UTF8. Он поддерживает NFSv2 и v3, но не v4. Он еще не поддерживает символическую ссылку (как клиент Microsoft).

Siwtch NFSv4 Client: вы можете оставить встроенный NFS Client для бесплатной эталонной реализации NFS 4.1 для Windows от UMICH CITI, хотя его сложно установить, но он должен либо устранить проблему (поскольку NFS4 явно требует UTF-8), либо сделать это возможным использовать обходной путь fuse-convmv, упомянутый выше.

Переключение ОС: в Windows Server 2012 добавлена поддержка сервера NFS 4.1, поэтому есть вероятность, что в них также включен клиент NFS 4.1.

Оба коммутатора не будут работать, если ваш сервер поддерживает только NFSv3, например, если вы используете OpenWRT (даже последняя версия сервера OpenWRT по-прежнему не может выполнять NFSv4).