The Windows Client: Native Access, Unix Permissions
Most MooseFS clients access a cluster through a POSIX mount. On Linux, FreeBSD, or macOS, mfsmount uses FUSE to make the cluster appear as a familiar directory tree.
Windows works differently. It doesn’t provide the same built-in POSIX layer, so one common solution is to mount MooseFS on a Linux machine and share it with Windows through Samba or NFS. That works, but it adds an extra server to the setup, and another set of permissions to manage.
The MooseFS Windows Client offers a more direct approach: it’s a native Windows file system driver that connects to MooseFS without needing a Linux gateway in the middle.
This post explains how the client works, why you might use it, and where Windows permissions differ from Unix permissions.
A native client, not a gateway
The Windows Client runs as a Windows service. Once it starts and connects to a Master Server, it makes the MooseFS namespace available as a drive letter.
From there, file operations go directly to the cluster. The Master Server handles metadata, while the Chunkservers store and serve file data. There’s no Linux mount or Samba re-export in between.
Windows and other MooseFS clients can also work with the same files because they connect to the same cluster. A file created on Windows is visible to a Linux client mounting the same MooseFS namespace, and vice versa. The data doesn’t have to pass through an SMB share to get from one platform to the other.
Mapping Windows users to Unix identities
The main complication is user identity.
MooseFS stores ownership and permissions using Unix user IDs (uid) and group IDs (gid). Windows identifies users with security identifiers (SIDs). The Windows Client translates between these identity systems when it performs operations or displays and changes ownership and permissions.
The mapping can use a fixed uid and gid configured for the client, or it can look up the logged-in Windows user through LDAP. In environments that already use Active Directory, LDAP can help the client display the appropriate file owner without requiring administrators to maintain a separate identity map by hand.
Where the client makes sense
The client is a good fit for Windows machines that need direct access to MooseFS data but do not need a separate Linux gateway. Typical examples include Windows application servers and workstations in an Active Directory environment.
It supports 64-bit Windows 10 and Windows 11, as well as Windows Server 2008 R2, 2012, 2016, 2019, and 2022.
As with mfsmount, version compatibility matters: the Master Servers and Chunkservers the client connects to must be running versions that are not older than the client.
Licensing: included with MooseFS PRO
The Windows Client is a MooseFS PRO feature. Its license is managed through the Master Server: the server holds a license file, and the client checks with that master whether it is authorized to run.
The licensing mechanism itself isn’t limited to a particular Master Server edition. A Community Edition master can hold the same license file and provide it to a connecting Windows Client, just as a PRO master can.
The important distinction is how the product is sold: the Windows Client is bundled with MooseFS PRO. It does not have a separate standalone license.
What has changed in the code
The Windows Client shares a significant amount of code with libmfsio, a library that lets programs call functions such as mfs_open and mfs_read directly, without accessing MooseFS through a mounted file system.
In May 2022, MooseFS 4.39.0 reorganized the shared code in mfsio.c. It introduced an internal API used by both the Windows Client and libmfsio, with a small translation layer for each. That structure makes maintenance simpler: improvements to the shared core can benefit both components instead of needing to be implemented separately for each platform.
Several Windows-specific changes arrived around the same period:
- MooseFS 4.38.3 (May 2022): Added
WSAPollsupport to theportable.hcompatibility layer andGetTickCount64support to the timing code inclocks.h. - MooseFS 4.43.0 (later in 2022): The changelog records only a fix for Windows issues.
- MooseFS 4.44.2 (December 2022): Added an option to set the minimum Master Server version the client will accept.
- MooseFS 4.45.1 (February 2023): Allowed
mfsioto accept the connection password in MD5 format.
These releases included both Windows-specific fixes and changes to the code shared by the client and libmfsio.
POSIX permissions, with Windows limitations
MooseFS is tested with tools designed to check file-system behavior against the POSIX standard, and it passes those tests. But POSIX was designed around a single machine, while MooseFS is distributed across a network. That means features such as caching, metadata synchronization, and file locking need to be designed with network behavior in mind.
The Windows Client uses the same Unix-style permission model as MooseFS, but Windows has some limitations. The limitation is that Windows itself does not use the POSIX permission model.
Unix permissions and Windows ACLs are different
In the traditional Unix model used by MooseFS, permissions are divided into three categories:
- Owner: the file’s owner
- Group: users in the file’s group
- Others: everyone else
Each category has read, write, and execute permissions.
Windows uses access control lists (ACLs) instead. An ACL can grant or deny specific rights to multiple individual users and groups. That model is more detailed than the owner/group/others permission bits stored by MooseFS.
The Windows Client exposes the Unix-style model: you can view and change permissions for the owner, group, and others. It accepts allow access-control entries, but not deny entries.
This difference matters when you edit permissions in Windows. If you try to grant a particular right to an additional user through the Windows permissions dialog, the operation fails because MooseFS has no corresponding Unix permission bit in which to store that rule.
Likewise, changing permissions from Windows only changes the read, write, and execute bits for the owner, group, and others. Other settings available in the Windows ACL editor can’t be preserved when the permissions are written back to MooseFS, because its stored metadata has no place to represent them.
In practice: the Windows Client gives Windows machines direct access to MooseFS, but it does not support the full Windows ACL model. Permissions remain based on the Unix owner, group, and others model that MooseFS stores.