Unix file system on windows

First published on MSDN on Feb 03, 2011

Installation & Configuration of Windows NFS Client to enable UNIX to Windows to Mount a UNIX File System

When migrating a SAP system from UNIX/Oracle or UNIX/DB2 to Windows/SQL it is sometimes useful to be able to mount a UNIX file system on a Windows server.  The

Network File System protocol

(NFS) is used by most UNIX and Linux operating systems such as Solaris, HPUX, AIX etc.  The Windows equivalent of NFS is

Server Message Block

known as SMB or CIFS

SAP fully support “heterogeneous” SAP application servers, that is a UNIX/Oracle or DB2 database server and Windows/Intel application servers.  The Windows platform offers integrated clustering/HA (documented, supported and free of charge from SAP) and single sign on.  Windows applications servers are fully supported on both Hyper-V and VMWare.

How to Setup Windows to UNIX File System Interoperability

There are several technologies to enable connectivity between Windows servers and UNIX operating systems:

1.      Samba is a freeware software available from

www.samba.org

that exposes UNIX server file systems as Windows (actually SMB Compatible) shares.  Samba also allows some integration into Microsoft Windows Domains & Active Directory.  Samba is configured and managed on the UNIX server and requires installation/configuration by the UNIX administrator

2.      Windows 2003 has an add on component called

Windows Services for UNIX

has a component called Client for NFS.  Services for UNIX setup is used to

add/remove Client for NFS

.

3.      Windows 2008 and Windows 2008 R2 the Services for Network File System have been made part of the File Server Role.  The Server Manager tool is used to

add/remove the Services for Network File System

as of Windows 2008 or later.  Windows 2008 and higher also has additional interoperability features for UNIX environments called

Subsystem for UNIX-based Applications

however installation of this component is not required to enable simple NFS connectivity

In all cases it is

highly recommended to use the Windows 2008 R2

product if possible.  Check the

SAP Product Availability Matrix

or post a question in this blog to verify if your SAP version is supported on Windows 2008 R2.  In general all SAP Kernel 7.0 or higher systems are supported on

Windows 2008 R2 since November 2010

.

Installation Tasks:

1.      Follow the

step-by-step procedure to add NFS support for Windows 2008 R2

and basic configuration

To install Services for NFS components

1.     Click

Start

, point to

Administrative Tools

, and then click

Server Manager

.

2.     In the left pane, click

Roles

.

3.     Under

Roles Summary

in the right pane, click

Add Roles

. The Add Roles Wizard appears. Click

Next

.

4.     Select the

File Services

check box to install this role on the server, and then click

Next

.

5.     Select the

Services for Network File System

check box, and then click

Next

.

6.     Confirm your selection, and then click

Install

.

7.     When the installation completes, the installation results appear. Click

Close

.

2.      Logon to the UNIX host and type

id –u <sid>adm

id –g <sid>adm

or while logged on as <sid>adm type id

3.      The next step involves “mapping” the Windows user id to the UID and GID of the <sid>adm account on the UNIX server

There are three ways of doing this, however in most cases we recommend option #1

Username mapping:

#1           Configure the

UID/GID using the registry entries

explained in this blog – (Recommended technique)

#2           Configure

Active Directory Lookup

or

ADLDS

(for Win2008 or higher) — optional

#3

User Name Mapping

if required (for

Win2003 see this post

) — optional

4.      Ensure the Windows host is defined in the /etc/hosts file on the UNIX server.  Add the UNIX server to the \Windows\Drivers\etc\hosts file on the Windows server

5.      Ensure NFS configuration (/etc/dfs/dfstab or similar) on the UNIX server is correct – the Windows hostname must be allowed to mount the file system usually

6.

Mount the SAP profile directory

using Windows Explorer or command line with the

syntax

unixserver:/export (recommended) or use the traditional Windows

\\servername\share

7.      Test creating and deleting a file

8.      Install a SAP instance using SAPInst or use SAPInst to export the UNIX/Oracle system to Win/SQL

Note: SAP requires that the NFS connection has a drive letter.  It is therefore always necessary to logon the Windows host and ensure the NFS drives are connected prior to starting the SAP application server.  NFS is not a particularly robust protocol therefore it is not to be used as a Export or Import location.  It is not permitted to export an SAP system to dump files on an NFS source.  In addition it is not recommended to store dump files on a NFS source and import on a Windows server.  Always read/write to dump files on a local disk

Several Great Uses of Windows to UNIX File System Interoperability

During OS/DB Migrations from proprietary UNIX systems to Intel/AMD commodity solutions the R3LOAD export/dump files need to be transferred to Windows.

SAP Migration Monitor supports FTP to transfer dump files to a Windows environment.  However this requires the installation of FTP on the Windows server.

There are three good reasons for establishing Windows to UNIX interoperability:

1.      The ability to use powerful Intel/AMD servers for the Migration.  This will greatly speed up the export/import process

2.      The ability to use SAPInst GUI to complete the full OS/DB Migration process without the need to use command line tools.

A full manual procedure for exporting and importing a SAP system

has been documented in this blog, however the latest versions of SAPInst for SAP Kernel 7.0 systems and higher can be exported/imported provided that the UNIX file system containing the SAP profiles is exposed.  SAPInst will check the profile directory before starting the export.  Provided a Wintel server can access the profile directory, SAPInst will allow a GUI based export of a UNIX system.

3.      Increasing numbers of customers are using modern Intel and AMD servers as SAP application servers connecting to UNIX database servers.   Modern Intel and AMD based servers are vastly cheaper than proprietary UNIX servers and deliver comparable or better performance.  SAP OLTP type applications such as ECC 6.0 usually require 60% to 80% of the system CPU resources on the Application Tier with the remainder on the Database Tier.  Therefore 60% to 80% of the SAPS (Unit of SAP workload sizing) can run on low cost Intel or AMD commodity servers.

As of February 2010 a typical fully configured SAP application server deployed in our customer base costs less than $15,000 inclusive of 96-128GB RAM service & support.

A typical medium size SAP system may have about 100,000 SAPS in total with 30,000 SAPS for Database Layer and about 70,000 SAPS for the SAP Application Layer (a typical 30% Database / 70% Application Tier split).  In this hypothetical case where the application workload requirement is equal to 70,000 SAPS, this requirement can be met with only 3 Intel or AMD servers at a cost of approximately $45,000 in total.  The energy consumption is much lower than UNIX systems and the rack space required is only 2U each or less if blades are used.

Many customers compare the workload capabilities of modern Intel and AMD based servers and the total all up cost including Operating System License, Energy/Aircon/rackspace, 3 year maintenance and administration + OS patching costs (practically zero for a Windows 2008 R2 server with

Internet Explorer removed

and all other

Windows features secured/disabled

) find that Intel/AMD based systems cost is 1/8

^th

to 1/10

^th

that of proprietary UNIX platforms.

Additional information about

Intel/AMD systems increase in market share

vs. UNIX system and

Intel displacement of high cost proprietary UNIX systems confirms a general trend to commodity type hardware

.

4.  Windows NFS Services also allows a customer to preserve a single SAP Transport directory and domain during a migration from UNIX/Oracle to Win/SQL.  During a period of 2-6 weeks the Dev and QAS systems are running on Win/SQL and the Production system is running on UNIX/Oracle.  It is still supported to transport configuration settings, SAP Security and ABAP programs from a Win/SQL Development system to a Production system running on UNIX/Oracle (because SAP is largely OS/DB independent).

Useful Links

Below are some useful links.  If you have any questions feel free to post them in this blog.

http://brneurosci.org/linuxsetup108.html

— a very good overview of setup and configuration process for Win2003

http://www.softpanorama.org/Net/Application_layer/nfs.shtml

— a generic overview of UNIX side configuration

http://technet.microsoft.com/en-us/library/cc785878(WS.10).aspx

– troubleshooting NFS Client (Win2008 R2)

http://technet.microsoft.com/en-us/library/cc737549(WS.10).aspx

– general overview of NFS Client  (Win2008 R2)

More information on SAP Benchmarks can be found on the

official SAP Benchmark website

.  The above statements about SAPS as unit of SAP sizing and cost of various hardware platforms are derived out from real SAP customer deployment or migration.  The term “SAPS” is used as a measure of equivalent workload.

SAP Note 80266 — Installing NT Applicn. Servers in UNIX Environment

SAP Note 97993 — Central NT/UNIX transport directory

Note 680617 — INST: Appl.Server in Heterogeneous SAP System Environment

Note 1067221 — Composite note for heterogeneous installation

Note 1148109 — Heterogeneous Inst.(Appl. Server Windows, DB Unix)

Thanks to:

Ashish Sahu — owner of

http://blogs.msdn.com/b/sfu/

Warwick Chai — owner of

http://www.bnw.com.au

Время на прочтение3 мин

Количество просмотров21K

Одной из приятных черт философии Unix, которую унаследовала Linux, является модульная организация файловой системы. И это, на самом деле, очень хорошо, так как в типичной установке ОС могут понадобиться различные файловые системы, вроде ext4, reiserfs, btrfs, или даже сетевые файловые системы — вроде nfs. Кроме того, в Linux существуют и виртуальные файловые системы, вроде /sys и /dev, которые помогают Linux сделать так, чтобы всё в ней выглядело бы как файл. Слабая сторона средств работы с файловыми системами в Linux заключается в том, что для создания механизмов, обеспечивающих работу файловой системы, нужно вносить изменения в ядро, или, как минимум, создавать загружаемые модули. Это, правда, не так уж и сложно, но, всё же, немного сложнее, чем разработка обычных программ. Решить эту проблему призван интерфейс FUSE (Filesystem in USErspace — файловая система в пользовательском пространстве). В частности, речь идёт о модуле файловой системы, который позволяет создавать новые файловые системы путём написания вполне обычного кода.

Картинка с сайта: habr.com

Мои любимые файловые системы пользовательского пространства

Существует несколько FUSE, которые способны принести тем, кто их применяет, реальную пользу. Вот некоторые из моих любимых:

• sshfs — монтирует удалённую файловую систему, используя лишь ssh-доступ.
• rclone — позволяет организовывать доступ ко многим удалённым файловым системам и осуществлять их монтирование.
• tagsistant — файловая система, основанная на тегах, облегчающая работу с большим количеством файлов.
• fuse-zip — позволяет монтировать zip-файлы в виде файловых систем.
• gitfs — позволяет монтировать в виде файловых систем git-репозитории.

Есть и множество других FUSE. Разнообразие подобных файловых систем позволяет использовать их в самых разных сценариях. Например — и для организации локальной работы с файлами, и для привлечения к работе с данными мощностей облачных провайдеров.

А как насчёт Windows?

FUSE в Linux — это весьма полезная штука. А есть ли что-то подобное в Windows? Да, нечто такое есть и в Windows. Называется оно WinFsp и выглядит как интересный механизм для работы с файловыми системами. Правда, прямой совместимости с FUSE у него нет. Но имеются слои совместимости с FUSE (один — для версии 2.8, и ещё один — для версии 3.2), которые упрощают портирование существующего FUSE-кода на WinFsp.

Это — достаточно новый проект такого рода. Но существует ещё один подобный проект — Dokan, авторы которого говорят о наличии интерфейсов к его API для FUSE. Правда, если верить бенчмаркам, выполненным в рамках проекта WinFsp, оказывается, что WinFsp отличается более высокой производительностью.

Итоги

Если имеется какая-нибудь FUSE, которая вам очень нравится, то она, вероятно, является опенсорсной. А если она вам и правда нравится — вы можете попытаться портировать её на Windows. Если вы не используете Windows, но хотите написать собственную FUSE для этой платформы, вышеописанные проекты дадут вам достаточно простые механизмы для переноса ваших трудов на Windows.

Например, у вас может быть некая система для логирования данных. Вы решили, что хотите представить результаты её работы в виде файловой системы. Сделать это не так уж и сложно. Так, например, имеются некоторые структуры данных, которые нужно заполнить, причём, заполнять нужно далеко не все эти структуры. Нужно написать функции, которые будут использоваться в виде инструментов для чтения и записи данных, представляющих директории и файлы. Вот — пример, написанный на C. А вот — C++-обёртка, которая позволит создать файловую систему, написав меньше кода, чем при выборе C. В этом примере имеется всего четыре простых функции. Так что — если вам нужна собственная файловая система пользовательского пространства — вы, что для Linux, что для Windows, вполне можете создать её своими силами.

Возникала ли у вас когда-нибудь необходимость в создании собственной файловой системы?

Картинка с сайта: habr.com

Modern organizations typically use a mixture of operating systems, including Unix, Linux, Windows and macOS. Network File System (NFS) is an open client/server protocol that allows organizations to centralize their data storage on one or more servers and enable seamless file sharing between their various operating systems.

This blog explains how to mount NFS Windows clients so users can access shared files over the network as if they were stored locally. It also provides best practices to optimize both security and performance.

Configuring NFS on Windows: Step-by-Step Guide

To allow a user to access remote NFS files, follow these steps to configure Windows mount NFS.

Step 1: Install the ‘Client for NFS’ feature on your Windows machine to set up the NFS client for Windows.

In Windows 10 or Windows 11, open Control Panel and go Windows Features. Expand Services for NFS and check the box next to Client for NFS, as shown below.

Картинка с сайта: blog.netwrix.com

For Windows Server 2012 and above, run the Roles and Features Wizard and select Client for NFS, as shown below.

Картинка с сайта: blog.netwrix.com

Alternatively, you can use an elevated Windows PowerShell session to install the NFS client Windows:

• For Windows 10 or Window 11, the command is:

Enable-WindowsOptionalFeature -Online -FeatureName ServicesForNFS-ClientOnly

• For Windows Server, the command is:

Install-WindowsFeature -Name NFS-Client

Step 2: Verify the client and connectivity.

Verify that the NFS Client service is running on your machine, as shown below.

Картинка с сайта: blog.netwrix.com

Of course, you must have connectivity to the designated NFS server. For a successful Windows NFS mount, ensure that the NFS Client service is running and the firewall allows NFS traffic. The default port is 2049.

Step 3: Perform identity mapping.

To enable Windows users to authenticate to a Unix server providing NFS exports, we need to map Windows users to the Unix user identifiers (UIDs) and group identifiers (GIDs) used by Unix-like operating systems. This mapping allows the Unix server to determine which user made the request for the NFS export.

Identity mapping can be done using any of the following methods:

• Active Directory (if integrated with the NFS environment)
• Local user mapping files
• Windows Registry settings

The first option is preferred for security and scalability reasons.

Method A (Preferred): Perform Identity Mapping in Active Directory (AD)

If both the Unix NFS server and Windows NFS client are joined to the same Active Directory domain, then we can use identity mapping in Active Directory. This is the preferred method whenever possible.

By default, a NFS client won’t look up identity mapping in Active Directory. However, we can change that by running the following command in an elevated PowerShell session on the NFS client:

Set-NfsMappingStore -EnableADLookup $True -ADDomainName “yourdomain.com”

You can add these LDAP options to specify your domain controllers:

Set-NfsMappingStore -LdapServers “dc1.yourdomain.com”,”dc2.yourdomain.com”

Restart the NFS client service.

Next, we need to configure our identity mapping. We can do that in Active Directory Users and Computers as follows:

1. Enable Advanced Features enabled under the View dropdown, as shown below.

• Right-click on the object you want to view and select Properties.
• In the Attribute Editor tab, select the uidNumber or gidNumber attribute and click Edit.
• Enter a value, and click OK to save your changes.

Alternatively, you can use the following PowerShell command:

Set-ADUser -Identity <UserPrincipalName> -Add @{uidNumber=”<user_unix_uid>”;gidNumber=”<user_unix_gid>”}

Replace the following:

• UserPrincipalName — The user to modify (e.g., user@domain.com)
• @{ … } — A hashtable containing the new attributes to add
• uidNumber — The Unix user ID (UID) for the user
• gidNumber — The Unix group ID (GID) for the user’s primary group

To perform this task automatically, create a CSV file containing user data and loop through it.

Method B: Perform Identity Mapping using Local Configuration Files

Using local user mapping files is a straightforward approach to establish correspondence between Windows users and Unix UIDs/GIDs without relying on Active Directory. This method uses two main configuration files:

• passwd — Maps Windows users to Unix UIDs
• group — Maps Windows groups to Unix GIDs

Both files are typically located in the C:\Windows\system32\drivers\etc\ directory. They follow a specific format, with each line representing a user or group mapping. When a Windows user attempts to access an NFS resource, the NFS service consults these files to look up the user’s Windows account name and retrieve the corresponding UID and GID, which are then used for NFS operations.

This method is simple to set up and manage in small environments and is particularly useful for standalone servers or workgroups. However, because it requires manual maintenance of mapping files, it doesn’t scale well for large environments. In addition, while it offers a solution for environments where Active Directory integration is not feasible, it’s important to consider security implications and regularly audit the mappings to ensure they remain accurate and secure.

Method C: Perform Identity Mapping using Windows Registry Settings

This method involves setting registry values to specify a default UID and GID that the Windows NFS client will use when accessing NFS shares. It’s particularly useful when you want all NFS access from the Windows client to appear as a specific Unix user, regardless of the Windows user account.

To implement this mapping, use the following PowerShell commands:

New-ItemProperty “HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default” -Name AnonymousUID -Value <unix_export_owner_uid> -PropertyType “DWord”

New-ItemProperty “HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default” -Name AnonymousGID -Value <unix_export_owner_gid> -PropertyType “DWord”

You need to reboot to have the new settings take effect. This mapping will apply to all NFS mounts made by the Windows client. After performing identity mapping, you can mount NFS in Windows using the command prompt.

Note that this method applies the same UID/GID to all NFS access from the Windows client, which may not provide sufficient access control in multi-user environments. In addition, modifying the registry requires administrative privileges, which could be a security concern. For these and other reasons, this method is considered an insecure approach and is not recommended.

Mounting in NFS means attaching a remote file system (exported by an NFS server) to a directory on the local file system of a client machine. When a client mounts an NFS share, it connects to the remote file system and makes it appear as if the NFS share is part of the local directory structure.

To mount NFS on Windows, map it to an available drive letter using the command prompt, as follows:

mount \\<nfs_server_ip_address>\<pathtonfsexport> Z:

Replace the following:

• <nfs_server_ip_address> — The IP address of your NFS server
• <pathtonfsexport> — The export path on the server
• Z — The drive letter to which the NFS share will be mounted on your Windows computer.

You can add additional options; for instance, mount -o anon specifies that the connection should be made anonymously, and mount -o nolock overrides the default file locking used by NFS.

After running the mount or mount o command,check whether the NFS share was successfully mounted by running the net use command to display all mapped network drives.

Troubleshooting Tips

Here are some errors that can arise during the mounting process and their typical underlying causes:

• Permission denied — Incorrect export settings on the NFS server or NFS rule blocking
• Access denied by server — Mismatched UID/GID between client and server
• Version mismatch — Client and server using incompatible NFS versions
• Mount point already in use — Attempting to mounting to a directory that’s already being used as a mount point
• No such file or directory — The export path on the server doesn’t exist

Best Practices for NFS Mounting on Windows

The following best practices can help you optimize security and performance when using NFS mounting on Windows.

Security

• Use strong authentication protocols such as Kerberos.
• Configure firewalls to segment the network and restrict NFS access from untrusted networks, allowing only necessary ports (TCP and UDP port 2049).
• Encrypt data in transit using secure protocols to safeguard data against eavesdropping and tampering.
• Limit NFS export permissions by granting the minimum required access and restricting client connections to specific IP addresses or hostnames.
• Regularly update and patch both the Windows client and NFS server to protect against known vulnerabilities.
• Enable detailed logging on the NFS server and monitor for suspicious activity.
• Use additional network security measures like VPNs for remote access.

Performance

• If possible, use NFSv4 or NFSv4.1 rather than NFSv3.
• Enable read and write caching on the client side to improve performance for frequently accessed data. You can do this using the following command: mount –o readcache,writecache.
• If security is not a concern in your environment, consider using the nolock option to disable file locking.
• Keep the Windows NFS client software up to date to benefit from the latest performance improvements and bug fixes.

FAQ

Does Windows 11 support NFS clients?

Yes, Windows 11 supports NFS clients.

How can I use NFS in Windows?

Here are some ways you can use NFS in Windows:

• You can provide access to the same file share using both the SMB and NFS protocols by using a Windows NFS file server.
• You can deploy a non-Windows operating system to provide NFS file shares accessible to non-Windows clients using the NFS protocol.
• To enable applications to be migrated from one operating system to another, you can store data on file shares accessible using both the SMB and NFS protocols.

What improvements are included in NFS version 4.1?

For complete details, visit the Microsoft NFS page. Key improvements in version 4.1 include:

• Remote Procedure Call (RPC)/External Data Representation (XDR) transport infrastructure, which offers better support and provides better scalability
• RPC port multiplexer 
• Auto-tuned caches and thread pools
• New Kerberos privacy implementation and authentication options

How do I add the server for NFS role service?

In Server Manager or Windows Admin Center, use the Add Roles and Features Wizard.

What Windows command-line administration tools does Server for NFS contain?

• Mount provides an NFS mount on Windows clients that maps to a local drive.
• Nfsadmin manages configuration settings of the Server for NFS and Client for NFS components.
• Nfsshare sets up NFS share settings for folders that are shared via Server for NFS.
• Nfsstat displays or resets statistics on calls received by Server for NFS.
• Showmount lists the file systems that have been exported by Server for NFS.

Картинка с сайта: blog.netwrix.com