On the UNIX NFS client, copy the file to a different name (you must do this as a user, not as root). Delete the original file in Windows NT and rename the file to its original name. Some Windows NT users and groups cannot be mapped to equivalent UNIX users or groups. Now open the properties of a folder you want to share using the NFS protocol and go to the NFS Sharing tab. Here click the Manage NFS Sharing button. On the new window check the Share this folder box. Step 2: Click Turn Windows features on or off. Step 3: Scroll down and check the option Services for NFS, then click OK. Step 4: Once installed, click Close and exit back to the desktop. Enable Write Permissions for the Anonymous User. With the default options you will only have read permissions when mounting a UNIX share using the anonymous user. Create and Configure the Shared Folder. Right-click on the new folder and select Properties. On the 'Properties' window, select the ' NFS Sharing ' tab. Select the ' Manage NFS Sharing.' In the NFS Advanced Sharing widget, check the ' Share this folder ' checkbox, then select Permissions. But first a short explanation on what user mapping does: If you want to connect to the Windows NFS share from Linux, and you don’t use a common authentication scheme like Kerberos, Linux will identify the user to Windows using their user ID and group ID (which every user and group in Linux has). It is easy to mount a drive from Linux NFS share on Windows 10 machine. To do that make sure you have NFS Client (Services for NFS) is installed from Programs and Features. When you mount NFS, your permissions you're mounting it with must match up with what you have on the server. For example, if your user has only read-only access, mounting it with read-write will cause you to see the same errors you mentioned in your post when you try to actually load the mount.
There are times when you need to access some Windows shares from Linux machines, or systems that have some Linux variations. A few methods exists on how you can do this, and NFS (Network File System) is one of them. NFS exists for a long time in Windows, starting with server 2003, and it’s still here in server 2012/R2. By sharing a folder using the NFS protocol, Linux users can map that share on their systems and use it as a central location for their documents. The only downside of using NFS is that you can’t have that granular control on those shares like you have in Windows, but usually read-write and read-only are enough.
Let’s begin by installing NFS on Windows, so open Server Manager, go to Manage and click Add Roles and Features.
Follow the wizard until you reach the Server Roles page. Here check the Server for NFS box under the File and Storage Services > File and iSCSI Services. You might also want to enable the File Server Resource Manager role if you want use some advance features of NFS.
Click Install to begin the installation.
If you want to do this using PowerShell, use the following command:
Using this command will also install the File Server Resource Manager role. Right now we are ready to share a folder using NFS, and there are three methods to do this: the classic one, the wizard one and the PowerShell one.
Configuring NFS shares using the Manage NFS Sharing option
As a tip, before we get started, do not name your directory that you want to share ‘NFS Share‘, or you will get an error when configuring permissions:
“Server for NFS cannot update the share configuration. Try updating the shared directory again, or delete and recreate the shared directory“
I found this during my testing, and I taught, why not share this with you! Now open the properties of a folder you want to share using the NFS protocol and go to the NFS Sharing tab. Here click the Manage NFS Sharing button.
On the new window check the Share this folder box. Now all of the other options and settings are available and ready to be configured. If you want to change the proposed share name which is the name of the the folder, you can do this from the Share Name box. Among the authentication options you can choose Kerberos v5 [Krb5] which uses the Kerberos v5 protocol for authentication, Krbv5i which provides integrity checking to verify that authentication data has not been altered, and Krb5p which provides privacy (new addition for Windows Server 2012). Unmapped user access is useful for scenarios where integration doesn’t occur between the clients accessing the shares. Unmapped user access has other two options: anonymous and unmapped user access. With unmapped user access, the server for NFS creates custom SIDs that correspond to the UIDs and GIDs for the UNIX accounts accessing the share. If you are using anonymous you need to put the power of Windows Firewall in place to deny access to the NFS service from all but the required IP addresses or subnets. Usually you don’t have to change these settings and just go with the default ones.
For more advanced share permissions click the Permissions button. This is where you can allow or deny computers form the network to connect to the NFS share, and where you set the access type for those computers. To allow them to connect, click the Add button, and in the Add Names box type the name or IP addresses of the clients you want to be able to connect to the share. You can add multiple clients at once, just separate them with a semicolon (;). Leave the type of access to Read-Write because this will be controlled using NTFS permissions anyway.
When you add multiple clients in the list and separate them with a semicolon, make sure no spaces exist in front or after that semicolon, or you will get an error message that then name cannot be resolved. Long story short… no spaces are allowed in that list.
Before you map this from a Linux client you need to set the proper NTFS permissions, or the client will not be able to read the share even tough is in the IP allow list. Switch to the security tab and add Everyone with the default permissions. If you want clients to be able to modify or write in this share, set the permissions to Modify and Write. The final access on the share is determined by both, the NFS permissions and the NTFS permission; the most restrictive permission wins. For more information on how NFS access works over NTFS permissions read this Microsoft Technet article.
Configure NFS shares using the Server Manager Wizard
This method is not valid for Windows operating systems older than server 2012. For those, you need to use previous method. Now open Server Manager, go to File and Storage Services and here click on Shares.
From the Shares section click Tasks > New Share.
The New Share Wizard opens. On the first screen select NFS Share – Advanced; because going with NFS Share – Quick we don’t get all the options and goodies.
Here is where you provide the share location. You can share the an entire volume by selecting it under the Select by volume section, or you can share a specific folder, by using the Type a custom path radio button.
In case you want to change the proposed share name, you can do it here from the Share name box. The remote share path will be automatically modified/completed for you.
On the Authentication page, chose the authentication protocols you want to use for this share then click Next.
Click the Add button to open the Add Permissions window. In the Host box, type the IP address or IP addresses for those Linux machine(s) that connect to this share.
And here are the NTFS permissions for this folder. As you can see the Everyone group is already in the list with Modify permissions. If you just want Read permissions for this share, select the Everyone group and click the Customize Permissions button.
On the Management Properties page, you are given the option to select what type of files are kept in this shared folder; for data management policies.
From this page you can set a quota for the folder. In case the already available quota templates are not good for you, no worries, you can customize the quota or create a new one after the folder is shared using the File Server Resource Manager console.
Click Create to share this folder using NFS.
At the end you should have some nice graphics that tells you how much space is used on the share and how is the quota limit staying (if you applied one). And that’s it, your folder is shared using the NFS protocol.
Configure NFS shares usingPowerShell
Just in case you are a scripting person, here is a simple PowerShell line that enables NFS sharing on a folder with the default settings:
New-NfsShare-Name"YOUR SHARE NAME"-Path"YOUR FOLDER PATH"-AllowRootAccess$false-Permission ReadOnly-Authentication all |
You can also put ReadWrite for everyone but is better to do this on a per machine basis, and here is how:
Grant-NfsSharePermission-Name"YOUR SHARE NAME"-ClientName"YOUR LINUX CLIENT IP"-ClientType"host"-Permission"readwrite" |
Now that the share permissions are in place, the next step is to configure the NTFS permissions. Follow this Microsoft Technet article on how to do it using PowerShell, or if you are in a hurry use the GUI to test this. Again, between the share permission and NTFS permissions, the one that is more restrictive wins. That’s why I set the share permissions to Read-Write so I can control the effective permissions trough NTFS.
Now log in to one of your Linux clients and open a terminal with root permissions. Go to your favorite path and create a new directory here using the mkdir command. This is needed in order to mount the Windows NFS share.
To mount the NFS share to the directory that was just created use the following command:
mount YOUR NFS SERVER:/YOUR NFS SHARE DIRECTORY/YOUR MOUNT FOLDER |
And here it is, the Windows share mounted on a Linux client. As you can see the client has Read-Write permissions, since it’s able to create files and folders in this share.
To make the mount permanent you will have to edit your /etc/fstab file, if not, the share will be un-mapped after reboot and you will have to use the mount command again.
This is all there is. Use whatever method you are more comfortable with because they all have the same result.
Want content like this delivered right to your
email inbox?
More similar articles
Recently we faced a scenario where a NFS share is created on a windows machine and UNIX client are trying to access it. (The behavior may be different based on the NTFS permission.)
Though UNIX showed full permission for the user; we were getting access denied while deleting the file in the NFS share! The investigation revealed a complex scenario.
Let’s discuss it.
This is based on our testing on our Lab machines:
On the Windows box; we created user user1 and a group grp1. Now, user1 was made a member of grp1 and set as primary group for user1. On the UNIX end; we created a user called user1 and a group grp1.
We configured User Name Mapping and Group Mapping.
A NFS share was created in windows box.
The NTFS permission for the share looks like this
C:NTFS-NFS <machine_name>grp1:(OI)(CI)(special access:)
READ_CONTROL
WRITE_DAC
WRITE_OWNER
SYNCHRONIZE
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_GENERIC_EXECUTE
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_EXECUTE
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES
NT AUTHORITYSYSTEM:(OI)(CI)(ID)F
BUILTINAdministrators:(OI)(CI)(ID)F
The effective permission for the grp1 is as below. It has all permission except the one highlighted.
+ So user1 will inherit the permission based on the permission given to grp1.
From UNIX side:
Mounted the NFS share as root.
The logged in as user1 (this user is mapped to user1 on Windows box).
Created a folder under the share 'user1_unix'.
For “user1_unix” observed the following
NTFS 'inherit' permission is not set (though if we create a folder from Windows box in the same location; it gets NTFS 'inherit' permission set).
The user1 is the owner of 'user1_unix'.
Permission for user1 on the 'user1_unix' is RWX.
grp1 has the permission that was given to parent directory.
Windows 10 Nfs Client Download
From UNIX though user1 has full rights on the folder which he created and is also the owner but still would not be able to delete it. Take a Netmon trace and you will see that rmdir call is being send over the wire with correct UID and GID. The consecutive reply shows the ‘err_access’ (permission denied).
Below is the input from the access calls
Below is the input from the access reply call
Windows Server 2008 R2 Nfs Share Permissions
Below is the inputs from the delete call (RMDIR)
Now from the windows box if you create a folder under the NFS share logged in as User1 then you would see that user1 is the owner and has full NTFS permission and is also able to delete the folder.
When can we delete files /folder from UNIX client?
1. If we grant 'delete subfolder and files' permission to the parent folder (nfstest) for grp1
2. If we grant 'delete' permission to the parent folder (nfstest) for user1
And the above two conditions are true whether or not we are inheriting the properties from parent folder.
Our findings:
·If we remove the 'delete subfolder' permission on NFS share for a user / group ; even if that user / group has explicit permission in some child folder in that NFS share; from UNIX side (even if we see RWX permission for that user) as that user we will not be able to delete the folder.
·From windows side when the users create a folder under the NFS share; he would be the owner and have full control in NTFS permission. Hence he would be able to delete the same.
BTW, NFS will ignore NTFS inheritance to comply with standard UNIX behavior.
Enabling KeepInheritance is recommended when files on NFS shares are meant to be accessed by both UNIX and Windows users and should be done on all the nodes in the cluster.
ØHKEY_LOCAL_MACHINESOFTWAREMicrosoftServer for NFSCurrentVersionMappingKeepInheritance
By default, the value of the KeepInheritance entry is 0, which means that newly created files and directories on NFS shares will not inherit ACEs from their parent directory. However, if an administrator wants to be able to read and write every file and directory created in a hierarchy, the administrator should set this value to 1 and set an inheritable read/write ACE at the root of the hierarchy.
You can refer to the TechNet article for the details on KeepInheritance.