AWS Storage Blog
Sharing data on Amazon FSx for OpenZFS across Linux and Windows clients
Many organizations need a high-performance shared file system that they can access simultaneously from Linux and Windows, despite different permission models across the platforms. For example, a media and entertainment enterprise may render workloads mutually on Linux and Windows clients. These customers may use mechanisms like “User Mapping” to make sure that their Windows clients can mount file systems shared via NFS and avoid file access conflicts.
Amazon FSx for OpenZFS is a fully managed AWS service providing scalable OpenZFS file systems for high-performance applications. It features data management capabilities like snapshots and encryption, supports over 1 million IOPS and 21 GB/s throughput, and is ideal for big data, DevOps, and research workloads. To bridge the gap between different operating systems and their unique permission models, organizations often use solutions like “User Mapping” for seamless file sharing via NFS.
In this post, I show how to use Network File System (NFS) protocol version 3 and different authentication methods available to concurrently share data stored on FSx for OpenZFS data to your Linux and Windows clients. That enables cross-platform data accessibility, enhanced security, and efficient data management, leading to improved productivity and resource optimization.
Background on NFS and Amazon FSx for OpenZFS
NFS is a native protocol on Linux and you can mount FSx for OpenZFS on Linux by using the standard Linux mount command and the domain name system (DNS) name associated with the volume.
You can access data on your FSx for OpenZFS file system by using NFS protocol versions (v3, v4.0, v4.1 and v4.2). Linux clients natively support NFS client versions 3 and 4.x and let you mount the file system using the standard Linux mount command. Windows clients support NFS version 2 and 3 and require installation of the NFS client.
You utilize NFS version 3 when connecting Linux and Windows clients concurrently to FSx for OpenZFS, since that is the NFS version supported by both platforms.
The AWS post “New – Amazon FSx for OpenZFS” provides information on setting up an FSx for OpenZFS file system.
Solution walkthrough
The following is a summary of the steps to implement this solution:
- Install and Configure the NFS client for Windows: this is required to mount FSx for OpenZFS on Windows clients using the NFS protocol.
- Mount the file system: you must mount the FSx for OpenZFS file system on both Windows and Linux clients in order to access the data.
- Select and configure the identity mapping and authentication method: you will choose between User Name Mapping server, Active Directory (AD) integration, or anonymous authentication to map and authenticate users to access the files on FSx for OpenZFS.
1. Install and configure the NFS client on Windows
You will need to install and configure NFS client on Windows.
Following are the steps to install the NFS client on Windows. This can be accomplished either via GUI or Windows powershell.
The following is an example using the GUI on Windows Server 2019 (this process also works in Windows Server 2022):
Installation
- Open the Server Manager on the Windows server.
- On the dashboard, select Quick Start, then Add Roles and Features, then Next in the dialog box.
- For Installation Type, select Role-based or feature-based installation and select Next.
- In the Server Selection screen, select your server name and select Next.
- On Server Roles, expand File and Storage Services.
- On File and Storage Services, select Storage Services and select Next.
- That will bring you to the final step. On the Features dialog, select Client for NFS and select Install.
Figure 1: Installing the NFS client on Windows Server
Configuration
After installing the NFS client on Windows, you will need to configure it. Use the NFS client on Windows Server GUI to customize client settings, default file permissions, and security model. The default settings (shown in the following) work for most environments. However, you must consider if the default file permissions address your security posture or match with the defaults on your Linux distribution.
Figure 2: NFS client on Windows Server – default file permissions
2. Mount the file system
Access the data by mounting the file system on the Linux and Windows clients.
- To mount the file system, you need its DNS name. Using the FSx console, navigate to the Network & security tab of your FSx for OpenZFS file system and copy its DNS name. In the following screenshot, I show the DNS name of one of my FSx for OpenZFS file systems:
Figure 3: Capturing the DNS name of the file system
2. Next, mount the file system on the Linux server using the file system DNS name and the following mount command (a basic mount command):
mount -t nfs -o vers=3 fs-04fcff18e33270111.fsx.us-west-2.amazonaws.com:/fsx/sync_vol /fsxsync
Figure 4: Mounting the file system on Linux
3. Finally, also mount the file system on the Windows server using the following command:
mount \\fs-04fcff18e33270111.fsx.us-west-2.amazonaws.com\fsx\sync_vol\ Z:
Figure 5: Mounting the file system on Windows
Refer to the FSx for OpenZFS documentation for steps to optimize file system performance.
3. Select and configure the identity mapping and NFS authentication method
Linux and Windows use different account and security systems. Linux represents users with user identifiers (UIDs) and group identifiers (GIDs). Windows represent users and groups with a unique security identifier (SID). User mapping is the process of converting UIDs and GIDs from Linux to SIDs from Windows and vice versa. User mapping provides a clean default permission set for Windows users to transparently access, modify, and create files.
After installing and configuring the Services for NFS as described in the “Background on NFS and Amazon FSx for OpenZFS” section, you must select and configure the appropriate identity mapping and authentication method. You can use User Name Mapping server, Active Directory (AD) integration, or anonymous authentication.
AUTH_SYS or AUTH_UNIX: using UID and GID identifiers for account mapping
AUTH_SYS or AUTH_UNIX account mapping is the process of matching the Linux UIDs and GIDs to corresponding Windows user and group SIDs.
The Microsoft Client for NFS supports two methods for account mapping: either use the %windir%\system32\etc\passwd method for standalone servers or AD for servers joined to a domain.
3.1 Standalone servers: the /etc/passwd method
The /etc/passwd method creates a one-to-one mapping of a Linux UIDs and GIDs to a Windows user and group SID.
1. First, provide a User Name Mapping server using the NFS Client for Windows. In our example, the mapping server is the server containing the password file.
Figure 6: NFS client on Windows Server – User Name Mapping server
2. Next, place a password (passwd) file on the Windows path %SYSTEMROOT%\system32\drivers\etc. Each Windows user/SID on the file is matched to a Linux user based on the UID and GID in the file.
3. Restart the NFS client on Windows after configuring the /etc/passwd file and mapping server. You can use the powershell commands nfsadmin client stop and nfsadmin client start for that. Make sure that the file system is unmounted on Windows before you restart the NFS client.
Figure 7: Restarting the NFS client
The following is an example of user mapping using the /etc/passwd file placed on the Windows client at %SYSTEMROOT%\system32\drivers\etc.
Figure 8: Windows passwd file example
Each line has the following fields separated by a colon: Windows username, Linux UID, Linux GID, description, Windows home directory.
In this example, I created a user called mary on both Linux and Windows. After logging onto the Windows server and mounting the file system, I can confirm that mary’s UID and GID (UID 1002 and GID 1007) are in effect by issuing the mount command (as follows). The NFS client mapped the UID and GID using the password file I provided.
Figure 9: mount point effective UID and GID
4. Next, create a file on Linux and check it on Windows. Using the account mary on Linux, I create the text file called mary-file-linux.txt on my FSx for OpenZFS file system mounted on /sync_vol. In the following, you can see the ownership, group membership, and permissions on the file mary-file-linux.txt.
Figure 10: file permissions – Linux
5. Now, check that file from the Windows side.
Logged in as mary on Windows, I open the drive where I mapped the FSx for OpenZFS file system. I can see that the file is accessible and preserved the same ownership, group membership, and permissions from Linux.
In the red boxes in Figure 11 you can see the file permissions, user ID, and group ID assigned by Windows.
Figure 11: file permissions – Windows file properties
6. Next, create a file on Windows and check it on Linux.
Using the account mary on Windows, I create a text file and save it on the Z: drive (the FSx for OpenZFS share).
Figure 12: sample text file saved on Z:
From Windows, I can see that the NFS client for windows assigned permissions using the Linux standard: Owner, Group, Other, and R, W, X. The permissions assigned use the default file permissions set in the NFS Client for Windows (Figure 3). In addition, it assigned the UID and GID from the passwd file found on the Windows side.
Figure 13: File permissions – Windows file properties
7. Next, check the same file on the FSx for OpenZFS Linux mountpoint. The content of the file can be seen and confirmed that the permissions and ownership shown on the Windows side match the Linux side.
Figure 14: File permissions – Linux
Furthermore, note that the user names do not have to necessarily match from Linux to Windows and vice versa. For example, in the following password file on the Windows side, I am mapping the Windows user jeff to a UID 1004. UID 1004 in my example is a Linux user called phill. Windows uses the UID for the mapping, not the Linux user name (phill in this case).
Figure 15: User name mapping – jeff to UID 1004 (phill)
3.2 Servers joined to an AD
1. For servers joined to an AD, you must select the identity mapping source in the NFS client to use your AD domain (“example.com” in my case).
Figure 16: NFS client on Windows Server – AD domain name
2. Next, you must update the user common name (CN) attributes in the AD Organizational Unit (OU). Use the ADSI editor to update the “gidNumber” and “uidNumber” on the Windows user to match the Linux UID and GID of the corresponding Linux user. Follow these steps:
a. Type “adsi” in the Windows search bar and open the editor in the AD domain server.
Figure 17: ADSI editor (AD editor)
b. Navigate to the Users subtree in the ADSI editor, selecting the desired user in the OU from your domain. Right-click on the desired user, and select properties.
Figure 18: ADSI editor – changing the CN of a user
In my example, I update the CN attributes gidNumber and uidNumber of the Windows user brian to match the UID and GID of the Linux user brian with UID 1013 and GID 1005.
c. First, I change the uidNumber attribute to 1013.
Figure 19: ADSI editor – changing the uidNumber attribute
d. Next, I change the gidNumber to 1005.
Figure 20: ADSI editor – changing the gidNumber attribute
3. I repeat the process for every user I want to map from Linux to Windows, and then I restart the NFS client when done. I use the powershell commands nfsadmin client stop and nfsadmin client start for the NFS client restart. Make sure to unmount the file system on Windows before restarting the NFS client.
4. Next, I create a file on Linux logged as user brian and check its ownership, group membership, and permissions.
Figure 21: Linux file details
5. Finally, to confirm, I check the file on Windows logged as user brian from the example AD domain. I can confirm that the Linux ownership, group membership, and permissions match the ones from the user brian, on Linux, as expected.
Figure 22: validating the user mapping using AD
3.3 AUTH_NONE: anonymous authentication
You can use anonymous authentication to map the user ID and group ID of a Linux user to your Windows client.
Anonymous authentication is a generic way to provide read/write access to the file system. But note that it does not provide a strict mechanism to arbitrate write access to files. Furthermore, you cannot setup permissions on a user/group level. Therefore, it is not the recommended method. It should be considered only in situations in which security is not a concern.
You must add the following registry keys and then reboot to setup anonymous authentication.
New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousUID -Value <Linux_uid> -PropertyType "DWord"
New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousGID -Value <Linux_gid> -PropertyType "DWord"
After adding the keywords and rebooting, you can mount the file system on Windows using the anonymous option (-o anon) as follows. Note that the UID and GID assigned -2, which means the anonymous access is in use.
Figure 23: anonymous authentication
Cleaning up
If you followed along and would like to remove resources used in this solution to avoid incurring any unwanted future charges, you can unmount the file systems and delete the FSx for OpenZFS file system by following the FSx for OpenZFS user guide.
Conclusion
In this post, I highlighted the method of using the NFS client on Windows Server to access data on the FSx for OpenZFS file system, enabling data sharing across Linux and Windows clients. I explored the process of mounting the file system, securing it through authentication, and tuning for performance.
The main takeaway is the potential to use the NFS protocol for shared file storage using FSx for OpenZFS across both Linux and Windows platforms.
The benefits include cross-platform data access, heightened security, and effective data management, which enhance productivity and optimize resources. By adopting this strategy, you not only harness the power of FSx for OpenZFS but also effectively bridge the gap between different operating systems.
Next, for a deeper understanding of the FSx for OpenZFS service, you can delve into the references section.