Organizations rely on enterprise file sharing tools to provide access for critical files from multiple devices and platforms. An enterprise organization’s IT landscape is usually a mix of Windows and Linux machines—in certain scenarios a single file share may need access by both Windows and Linux machines at the same time. Managing this could get complex as Windows and Linux follow different security semantics and protocols. This is just one of the many challenges of cloud file sharing.
This blog will explore multi-protocol file sharing and show you how to set it up with Cloud Volumes ONTAP, giving you an easy way for Windows and Linux servers in mixed environments to access the same volumes.
NFS vs SMB
Server Messaging protocol (SMB) is the native file sharing protocol implemented in Windows systems. SMB uses share level and user level security to authorize access to file shares. The Common Internet File System (CIFS) protocol is a dialect of SMB which in turn is a collection of message packages that defines a specific version of SMB. The Network File System (NFS) protocol is used by Linux systems to share files and folders. NFS mount options use export policies in addition to file and folder permissions as a security mechanism. When the same volume must be shared between Windows and Linux systems, interoperability between these mechanisms is essential and also quite complex to achieve.
Let’s dig deeper into some of the key differences between SMB /CIFS and NFS protocols:
Authentication mechanism: Authentication for NFS shares is handled either by a local password /group files or by a Linux-based directory service that looks for a user identifier (UID) or group identifier (GID) match. SMB authentication is done using the user’s SID and is handled by Active Directory.
Security: In NFS mode, bits (NFSv3) and ACLs (NFSv4) are used to determine the permissions for a user. Access ACLS determines the permissions that the user has on an SMB share.
Rename policy: NFS allows users to rename components of an open file while it is not supported in SMB.
Locking policy: The NFS file lock range can be set to either mandatory or advisory depending of the protocol version being used. For SMB shares, the lock ranges are mandatory.
Beyond SAN Storage: Multiprotocol NAS
Enterprise NAS storage often complements SAN (Storage area network) storage. SAN is a dedicated network of devices providing block-level storage via Fibre Channel and over TCP/IP.
Multiprotocol NAS, on the other hand, can be leveraged in enterprise file sharing landscapes where there are many use cases for single file shares needing access by Linux servers and Windows Server at the same time. Multiprotocol NAS can also be used for centralized storage of logs from multiple servers that can be processed by an analytics solution.
Some organizations also prefer NAS file shares to store backups taken from Windows and Linux servers. Another possible use case for multiprotocol access is when corporate laptops are a mix of Linux and Windows flavors. For instance, open source developers typically prefer Linux working environments, but Microsoft stack developers would prefer Windows OS. However, they both might need to access the same volume to share project-related files. In such scenarios, configuring interoperability could be a challenge.
Mounting NFS in Windows
While it is possible to configure Windows servers to enable communication with NFS and Linux servers to access shares over SMB, the configuration steps to do so are complex. To use NFS with Windows, the role should be enabled from Server Manager or through PowerShell. In addition to that, User ID mapping and Group ID mapping should be configured so that users from Windows domains can access the files in the NFS share. Alternatively, RPCSEC_GSS, a Kerberos V5-based protocol, can also be used for authentication and better security; however, identity mapping is still going to be required. Configuring anonymous access eliminates most of the complex identity mapping requirements, but that introduces a security risk as the share will be mounted using root user privileges.
Mounting SMB in Linux
Mounting SMB shares in Linux also requires additional configuration for access and authentication. Administrators can use Samba tools to access SMB shares from Linux. Depending on the CIFS module and SMB protocol version, not all SMB features will be available. A credential file should be created for authenticating to the SMB share with details such as Windows username, password, domain, etc. In multi-user scenarios, users also need to provide their individual credentials using the cifscred utility, which is used for passing on user credentials to a kernel when CIFS is mounted with a multi-user option.
From all of this it’s clear that using the same share for Linux and Windows is not an easy job, and the cloud isn’t helping. The major cloud file service offerings, such as Amazon EFS, Amazon FSx, or Azure Files, either provide access to NFS or SMB, not both. Cloud Volumes ONTAP offers a solution: support for both NFS and SMB access for volumes on AWS and Azure.
Cloud Volumes ONTAP for SMB and NFS
Cloud Volumes ONTAP offers a versatile enterprise file sharing storage for hybrid and multicloud environments, with many advanced storage features such as high availability, data protection, cost-saving storage efficiencies, data tiering, and more. With Cloud Volumes ONTAP, data can be accessed over SMB, NFS, or both at the same time, which allows Windows and Linux environments to have concurrent access to the same files on the same volume.
How to Configure Multiprotocol Access
Configuring multiprotocol access can be done through a set of simple steps. Note that this can be done starting with NFS and then switching to SMB/ CIFS, or vice versa. In this example we are going to start with an NFS volume and then add SMB/ CIFS.
Let’s start by logging in to NetApp Cloud Central.
1. From My Services click on “Go to Cloud Manager”:
2. Once you enter the Cloud Manager, you can see the working environments listed, which includes the Cloud Volumes ONTAP system as well as on-prem ONTAP systems:
3. For this walkthrough we will create NFS volume in Cloud Volumes ONTAP deployed in Azure. Select Cloud Volumes ONTAP deployed in Azure and click “Resources” in the quick navigation pane:
4. Click “Add new Volume”:
5. Provide the name and size of the volume and configure NFS export policy, specifying the network range to which the volume can be exported:
6. In the next configuration pane, select the usage profile, disk type, and tiering policy for the volume. When entered, click “Go” to create the volume:
7. Next, we need to complete the SMB/ CIFS set up. Select the Cloud Volumes ONTAP instance from the working environments and click on “Resources” (repeating Step 3). This time, select “CIFS setup” from the dropdown menu on the right-hand side:
8. Add details for the DNS primary IP, secondary IP, and Active Directory domain to join and the credentials to join the domain and click “Save”:
9. Click on “Advanced” to add additional details like CIFS server NetBIOS name, Organizational Unit, and DNS domain:
10. For completing the remaining configuration, we need to access System Manager. From Cloud Manager select the “System Manager” link from the dropdown menu on the right-hand side:
11. You will get a prompt stating that you will need network access to the Cloud Volumes ONTAP instance. Click ”Launch” to open System Manager:
12. Create a CIFS/SMB share from System Manager.
To do this, go to Storage > Shares > Create Share in System Manager:
13. Next, username mapping for Windows and UNIX usernames should be configured from the System Manager. This allows Windows users to access files on the created volume from the share using UNIX file permissions and vice versa. If individual-level file tracking is required, it is advisable to use conversion rules for a 1:1 conversion of Windows users to UNIX, or vice versa.
You could also configure a default user mapping for all users not covered by a name-mapping or conversion rule. This configuration is done by going to SVM settings > Host users and groups > Name Mapping > Add. The following example shows a conversion mapping from a Windows user to a UNIX user:
After completing the configuration steps above, the share can be accessed from Windows Server through Windows Explorer using the SMB protocol. The same share can be accessed from Linux servers by mounting it to a local folder using the “mount” command.
Note that user mapping is one option for configuring authentication to allow users from Windows and Linux to access the volume. It can be used when the number of users who need access is limited. However, in use cases where a large number of users need access to the same share (e.g., file shares) it is recommended to use a Kerberos NFS configuration. You can find more details about Kerberos and NFS here.
NetApp has been providing enterprise data storage solutions with multiprotocol access for years: now that’s possible in the cloud and hybrid architectures with Cloud Volumes ONTAP. Cloud Volumes ONTAP provides an innovative solution for solving the issues of sharing files between disparate environments. It simplifies the process of sharing data across the organization.
Make sure to read the rest of our cloud file sharing articles, with posts on SMB access with Azure Files, NFS file service with Amazon EFS, attempting to use Amazon S3 as a file share, how to set up NFS file shares for Kubernetes with Trident, unifying disparate data centers into a single source of data, and many other file share challenges.
Sign up for the 30-day free trial and explore how Cloud Volumes ONTAP can simplify enterprise file sharing through multiprotocol support.