Skip to main content
RHEL clients displays Anonymous UID and GID in the permission for the files and folder that are shared over NFS v4.1
Getting Network Error 53 "Network path not found"
Recently we got a case where customer was unable to access NFS share from Windows 2008 R2, Client for NFS.
We tried mounting the NFS share using the command below:
The error we got after the command was completed was "Network Error 53". Then to test the access, we tried mounting the share using the Map Network drive. It prompted for a user name and password. We observed the same behavior while trying to use the UNC path to access the share.
Later we found that the directory on the Solaris box, which we were trying to access, was shared both through SMB and NFS.
So, while we were trying to use the mount command, Windows client was assuming the share to be a SMB and failing. Due to the same reason, we were getting prompted for User name and Password.
Then we change the priority list in the provider order. We moved NFS on above "Microsoft Windows Network" and restarted the Client for NFS service. Provider order can be found under Network connection => Advance => Advance settings =>Provider order
Once we do this, the Multiple UNC Provider (MUP) checks for this request against the network providers according to their priority listing. Each network redirector responds back with a handle to the wanted resource.
Hence, when we moved NFS on top of "Microsoft Windows Network", mount command started working as it was assuming it to be a NFS share. Even through UNC
things worked and we were not prompted for user name and Password.
This is applicable in case same directory is shared from Unix server through NFS and SMB. In other scenario, provider order does not matter a lot.
Getting Red X sign on mounted NFS volume from Windows client
Windows NFS client is known not to handle multiple path NFS shares. The issue is by design and comes when the client is mounting an NFS share which is more than 26 characters in length.
Users would be able to access the NFS shares after mounting it to a drive letter but a red X (disconnected) sign would be there on the mounted volume. The NFS mounted drives will be in connected state even if UI shows disconnect.
The recommendation would be to have a single path nfs share like "\\servername\sharename" or a multipath NFS share having less than 25 characters.
How can we control the permission on the files created from Windows NFS client
We do get a lots of issue where the customer reports that "Permission ere not getting inherited on the newly created files and folder on the NFS client side". This scenario is intended for the scenario where Windows is the NFS client (running "client for NFS") service.
Usually the confusion is that the permission on the newly created files / folders should get inherited from the server to the client. In case on Windows acting as "Server for NFS" we can enable the "keepinheritance" registry key. More inputs on "KeepInheritance " is given in the article below:
I am not sure, if there is anything equivalent on the Unix side.
So the default behavior is the permission of the newly created files and folder depends on the NFS client from where it has been created and not on the NFS Server. This behavior is similar to the UMASK on Unix world. Hence the permission gets inherited when the files and folder are on the same local location.
In case of NFS access, where server-client is involved, the permission on the newly created files and folders depends on the setting on the NFS clients. In case of Unix environment, UMASK controls this. In case of Windows, we have an umask equivalent ( refer the image below).
Default
As per the customer's requirement, he had set the permission on the NFS share as '777' on the Server side and wanted similar behavior on the NFS client side. To resolve the issue, we made the changes below on the "client for NFS' properties and restarted the 'client for NFS' service.
Modified
IDMU tools missing from RSAT installation on Windows 8
IDMU tools is not part of the RSAT installation for Windows 8. There is a documentation error on the support article https://support.microsoft.com/kb/2693643/en-us talks about the presence of IDMU tools under RSAT.
However this has been added back on Windows 8.1 and now IDMU is a part of the RSAT tools for Windows 8.1 released though https://www.microsoft.com/en-us/download/details.aspx?id=39296
Installing SUA components on Windows 8
Recently, after the build conference we installed Windows 8 Developer preview edition here. I was checking different components related NFS, IDMU and SUA. While trying to install SUA components I noticed that it is marked as [DEPRECATED].
Looks like we are planning to move away from SUA components. I will get back here once we have some updates on the time frame on this.
BTW, the installation was smooth. There is no SDK released so far, after the installation it will redirect to download the SDK from https://www.microsoft.com/download/en/details.aspx?id=2391 (SUA SDK for Windows 7 / Windows 2008 R2) link.
Issue opening files created in Windows EFS directory from UNIX clients over the NFS connection from Windows Server 2008 R2
In recent past, we did have multiple customer reporting issues on files getting corrupted for the below scenario "files created in Windows EFS directory from UNIX clients over the NFS connection"
The environment in questions was Windows 2008 R2 as NFS server and Linux client as NFS client.
With our troubleshooting and research we found out that the issue is due to the way the users' token impersonation in done in Windows Server 2008/2008 R2. The behavior is by design. In addition to that, we also were able to find another very important piece of information about EFS and NFS combination. It turned out that when using EFS, the files and folders, created from the UNIX NFS clients, can only accessed from the UNIX NFS clients. The corresponding Windows/AD users on the Windows systems locally or over the network will not be able to access them as long as they are encrypted. This is a by design in Server for NFS component in Windows Server 2008 and Windows Server 2008 R2.
For example, if we create a file from Unix clients on an EFS NFS share, you would be observe the below information in the properties of the file. This is the reason why the mapped AD user is unable to open the file from Windows NFS server.
Hence, to conclude we can say EFS over NFS have not been tested and is not recommended. Using BitLocker would be a better option to secure the environment.
Issue where the timestamp are removed while copying files from the drive to the NFS shares
The timestamp gets modified to the current system date, while the files are copied from local drive to mounted NFS drive. File timestamp could be important for auditing purpose, running backup tools or for other reasons.
The effected Windows O/S are:
- Windows 2003, SFU 3.5 , Client for NFS
Windows 2003 R2, Client for NFS
Example
1: We mount a NFS share on Windows 2003, NFS client to a drive. Then we copy a file from local C:\ drive which has a time stamp (Tuesday, September 14, 2010, 11:04:37 PM) to the mounted NFS drive. After the copy the timestamp gets changed to the current system time.
During our testing we found that the issue looks like a bug with the NFS client and the behavior is inconsistent. We also tested another scenario:
Example
2: We mounted the NFS share on Windows 2003, NFS client using the mount command and also tried browsing the NFS share on the same machine through UNC. While the timestamp issue was still there while we were copying files to the mounted drive explorer windows, the issue could not be reproduced while copying the files to UNC explorer windows.
But this behavior was not consistent.
However the issue is not there with Windows 2008/2008 R2, client for NFS.
Owing to the fact that both SFU 3.5 and Windows 2003 are outside mainstream support, this bug will not get fixed. The URL below talks about the lifecycle for both the products.
https://support.microsoft.com/lifecycle/?p1=3207 ==> SFU 3.5
https://support.microsoft.com/lifecycle/?LN=en-us&p1=3198&x=7&y=13 ==> Windows 2003
Our recommendation on this would be to upgrade to Windows 2008/2008 R2.
Issues while upgrading from Windows 2003 to Windows 2008
Recently, we were trying to upgrade WIndows 2003 to WIndows 2008. WHile trying to upgrade, we ran into couple of intresting issues. This blogs talks about the issue faces during the upgrade.
First issue:
So the first thing which we would need is to update the version on Windows 2003 to Windows 2003 SP1. So, we will upgrade to windows 2003 SP2, reboot and again try to upgrade to Windows 2008.
Second Issue:
Hence we would need to run the Adprep command ( Adprep from Windows 2008). So, we will run the command adprep /forestprep
Type C in the command prompt and hit enter. Once it completes, then we need to run
Adprep /domainprep
D:\sources\adprep>adprep /domainprep
Running domainprep ...
Adprep detected that the domain is not in native mode
[Status/Consequence]
Adprep has stopped without making changes.
[User Action]
Configure the domain to run in native mode and re-run domainprep
Third Issue:
"Configure the domain to run in native mode and re-run domainprep"
Hence we make the changes below:
And then again run the command and this time it is successful:
ADPREP /forestprep must be run on the Schema Master of a forest and under the credentials of someone in the Schema Admins and Enterprise Admins groups.
ADPREP /domainprep must be run on the Infrastructure Master of a domain and under the credentials of someone in the Domain Admins group.
Once the above issues were fixed, we were able to install and add a WIndows 2008 into the domain.
LDAP calls made from the Unix client query incorrect login shell attribute
Recently while working on an issue where we got an issue where the Users once logged into Linux client were getting incorrect login shell. Changing the Login Shell in Active Directory (from Unix Attribute Tab), did not work as the user were still getting default login Unix Shell.
For example ==> This is the default view from ADUC ( Unix attribute tab)
Default Login Shell value is /bin/sh. Then we changed the value to /bin/ksh but still the user was still getting /bin/sh shell while logging on the Linux Client machine.
Environment: Windows DC is configured as NIS Master Server and client is using Kerberos for Authentication.
Since the Login Shell attribute information is stored in the Active Directory, we ensure that AD Replication is good. Linux client are making LDAP calls to the Domain Controller to query various information, including login shell.
From the Network traces to check on the calls made by the Linux client to the Domain Controller for querying the information. And it revealed that client is requesting for msSFU30LoginShell attribute and not for loginshell attribute.
Snippet from netmon:
+ Filter:
(&(sAMAccountName=unixtes)(objectclass=user))
- Attributes: ( objectClass )( sAMAccountName )( userPassword )(uidNumber )( gidNumber )( gecos )( unixHomeDirectory )( msSFU30LoginShell )( userPrincipalName )( displayName )( memberOf )( nsUniqueId )( modifyTimestamp )( uSNChanged )( shadowLastChange )( shad
We also confirmed that in Active directory store the information is stored in the attribute called loginShell and not in the attribute – msSFU30LoginShell. Actually, when we use to extend the schema on Windows 2003, SFU 3.5 by installing "Server for NFS" , the attribute was called mssfu30Loginshell.
Hence the issue was, the client is requesting a wrong attribute which does not have value and hence not getting any response. Based on further research, we found that sssd.conf file was configured to pass this information on the Unix client.
- ldap_user_shell= msSFU30LoginShell
We changed it to the loginShell and now we see that client is sending ldap query for loginShell and got the correct value in return - /bin/ksh.
Snippet from netmon:
- Filter: (&(uidNumber=10001)(objectclass=posixAccount))
- Attributes: ( objectClass )(uid )( userPassword )( uidNumber )( gidNumber )( gecos )( homeDirectory )(loginShell )( krbPrincipalName )( cn )( memberOf )( nsUniqueId )( modifyTimestamp)( uSNChanged )( shadowLastChange )( shadowMin )( shadowMax )( shadowWarn
Please refer following documents for more information.
https://technet.microsoft.com/en-us/library/bb463172.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms676844(v=vs.85).aspx
https://linux.die.net/man/5/sssd.conf
Mapping Unix account through ADlookup not working
Recently, we had a case where mapping Unix account through ADlookup was not working. Windows 2008 R2 as hosting the NFS share and Windows 2003 R2 was the DC. We performed the steps below:
- Populated User's attribute in AD
- Configured the Netbios name in the NFS properties page
- Updated the NFS related drivers
- Configured NFS share and gave proper NTFS permission (where the mapped user was made the owner and added into the NTFS permission).
This was a cluster environment. While accessing the shares from Unix clients we were getting "Permission denied". We checked the permission on the User's container in the AD and added READ permission for the authenticated users. Restarting the Server for NFS service had no impact. Still we got the same error.
Moving forward we collected NFS WMI traces along with the netmon (Network) traces. Though the Netmon traces did not give much input but from the NFS traces we could see that there was a conflict due to duplicate GID, which was causing the issue. This was an important learning, as NFS access over NFS checks UID and GID and both needs to be unique to get proper access from UNIX side.
Getting ldifde exports for the users, pointed to the duplicate entry. Removing the duplicate entry for the group resolved the issue.
More about Netgroup over NFS
This article discusses lookup mechanism for netgroups. We have multiple customer coming in with the request to restrict the NFS access using Netgroup. Client fencing for NFS is also discussed on the blog
https://blogs.technet.com/b/filecab/archive/2012/10/09/how-to-perform-client-fencing.aspx
Creating Netgroup can be achieved through Powershell command as discussed on https://technet.microsoft.com/en-us/library/jj603094.aspx
The first command creates the Netgroup in the root of the domain.
Running the second command "Set-Nfsnetgroup" command to add a host entry, it creates a separate object for each entry. This is how netgroup.byhost in LDAP is maintained. In AD, the attribute which gets populated is nisNetgroupTriple.
For example:
è testps is the Netgroup name and the IP address is the host entry added to the Netgroup.
An interesting observation we saw in our test environment was, while testing around the nisobject created for the host entries.
On the object, there is an attribute called "nismap" which has the Netgroup name.
First put a garbage value on that attaribute and restarted Server for NFS.
Then deleted the object and "server for NFS" service was restarted.
For both of the steps above, Server for NFS service was restarted and did not see any issues mounting / accessing the NFS shares from Unix based NFS clients.
This was just done for testing and hence not recommended to follow the same steps on Production environment.
There is another option for creating Netgroup by using the nismap command which comes with the IDMU utility. This is a legacy application and not recommended for using the nismap functionality over NFS, but works as per our test environment.
- nismap add –a <domain name> -e " <mapname> (host,user,domain)" Netgroup
Adding the netgroup created by 'nismap' command works and we can configure client group in the NFS permissions.
"net use" command against NFS shares is not supported under wow64
Recently we have a problem with "net use" command on Windows server 2008:
We launched a command prompt from c:\windows\system32\, executed a net use command to NFS share (Unix NFS Share), after a few seconds it resulted in a mapped drive on Windows.
On the contrary, when a command prompt was launched from c:\windows\syswow64\ folder, net use command to UNIX NFS file share errors with exit code 53 "Network path not found".
This turns out to be a known behavior as The NFS network provider dll (nfsnp.dll) is required for net.exe support for NFS. No 32-bit version of nfsnp.dll is shipped on 64-bit SKUs.
"net use" command against NFS shares is not supported under wow64.
nfsfile command does not run on mounted NFS volume
While working on a recent issue, customer reported that running the nfsfile command against a file on a mounted drive returns the error below. This was tested on Windows 2008 R2, running client for NFS.
So on the customer's environment, once the NFS share was mounted on the Windows, they tried running the nfsfile command from the command prompt against a file on the mounted drive, which failed.
But running the 'nfsfile' command worked on the all other files in the box. Informed them that NFSfile (Nfsfile.exe) is a command line tool that allows you to convert the custom SIDs created by Unmapped UNIX User Access to the mapped SIDs (regular Windows SIDs) used by a mapped user access method. It can also be used to view and manage the permissions assigned to NFS
shares using UNIX–like mode bits.
NFSfile command will not work on mounted NFS drivers as there is no way it can get the NTFS permission from them.
Services for UNIX Team - Microsoft
Recently, we have a case where the customer was unable to copy the Password Sync encryption key from...
Author: rohitban Date: 09/20/2011
Renaming a Windows NIS domain name may become essential as default NIS domain that IDMU captures is...
Author: abhisekbasu Date: 09/19/2011
As discussed on my earlier Blog post:...
Author: rohitban Date: 05/27/2011
We do get lot of issues where customer has migrated\upgraded from SFU 3.5 to Windows 2003...
Author: rohitban Date: 05/25/2011
On Windows 2003, SFU 3.5: In SFU 3.5, the default logon type is 'local system'. We can...
Author: rohitban Date: 05/25/2011
There was an issue in Windows 2008 R2, where the Unix clients were unable to honor the NTFS style of...
Author: rohitban Date: 04/20/2011
Recently we got a case where customer was trying to do a backup of a NFS share using Symantec. He...
Author: rohitban Date: 04/12/2011
We had a scenario where the customer was looking for a option to run the nismap command on a DC...
Author: rohitban Date: 04/06/2011
Recently, we got a case where the customer wanted to programmatically access NFS share using Windows...
Author: rohitban Date: 04/06/2011
Recently we got a case where customer informed that intermittently he is getting access denied error...
Author: rohitban Date: 04/04/2011
Recently we got an issue where the Users from Unix clients were getting permission denied while...
Author: rohitban Date: 04/04/2011
I came across a scenario where mount command was failing when we put it across the Cluster IP /...
Author: abhisekbasu Date: 04/03/2011
Most of the domain controllers running on Windows 2003 and serving purpose of Server for NIS for...
Author: abhisekbasu Date: 04/03/2011
Recently we had an issue where the user from the Unix clients were unable to run the...
Author: rohitban Date: 03/17/2011
We got an issue where customer was running an automated process on the Unix NFS clients that creates...
Author: rohitban Date: 03/07/2011
Recently, we faced couple of issues with Server for NIS. The environment looks like: 2 Windows 2008...
Author: rohitban Date: 02/21/2011
In case you want to setup sendmail on SUA and use your MS Exchange to actually receive the mail and...
Author: abhisekbasu Date: 02/21/2011
Recently we got a case where customer was having issue starting Client for NFS service. It was...
Author: rohitban Date: 02/15/2011
Recently we had a customer, who was having issue binding the HP UNIX client to Windows 2008 R2...
Author: rohitban Date: 02/03/2011
In one of the recent issues reported; members of the administrators group were unable to issue...
Author: abhisekbasu Date: 01/17/2011
I am finally back here J in this year. Recently, I have spent some time to find the steps to install...
Author: abhisekbasu Date: 01/14/2011
Recently we had an issue where User Name Mapping were not working through ADlookup. Initially it...
Author: rohitban Date: 01/12/2011
What registry keys can be modified, if the number of Unix clients are more? We can make the...
Author: rohitban Date: 12/09/2010
Why we are unable to do a persistent mount across logons? Even using the command below to mount NFS...
Author: rohitban Date: 12/09/2010
Why I am unable to change ownership from Windows clients? This is due to the default Unix style...
Author: rohitban Date: 12/09/2010
How can we map users in Windows 2008? In windows 2008\2008 R2, we have the following options: 1....
Author: rohitban Date: 12/09/2010
Unix style permission is bit different from Windows style permission. Files and directories are...
Author: rohitban Date: 10/20/2010
Recently we got a case where customer was having issue fetching the maps from the group and passwd...
Author: rohitban Date: 09/30/2010
Recently we got a case where customer was looking for mapping local users on Windows 2008. The first...
Author: rohitban Date: 09/30/2010
Please find the list of Hotfix for SFU 3.5. For Server for NFS:...
Author: rohitban Date: 09/02/2010
With the advancement in virtualization technologies, there has been an increase in the way shares...
Author: devendra1 Date: 08/24/2010
Please find the list of patch, one need to install to update the Server for NFS related drivers in...
Author: rohitban Date: 08/23/2010
Recently we got a case where customer was getting error while running the tar command with the P...
Author: rohitban Date: 08/20/2010
Recently I faced a scenario where Solaris 10 systems were unable to mount the NFS share from a...
Author: abhisekbasu Date: 08/20/2010
Recently we got a case where customer was unable to access NFS share from Unix client. The share was...
Author: rohitban Date: 08/18/2010
Recently we got a case where customer was sharing files through NFS between Windows and Macintosh....
Author: rohitban Date: 08/13/2010
In my last post; the execution of Win32 commands through RSH was considered. Although the method...
Author: abhisekbasu Date: 08/12/2010
Recently we got a case in which customer was using SFU 3.5 and Server for NIS was installed....
Author: rohitban Date: 08/12/2010
We recently had a query, where customer was trying to configure the following registry key so that...
Author: rohitban Date: 08/06/2010
Very often we get requests to setup environment where client will connect to Windows RSH server and...
Author: abhisekbasu Date: 08/06/2010
Recently we got case where password Sync was not working. Customer had configured password Sync on a...
Author: rohitban Date: 08/03/2010
Consider this scenario: 1. Solaris 10 Sparc is working as NIS Master. 2. We have also, installed the...
Author: abhisekbasu Date: 08/03/2010
Recently we worked on an incident where we trying to execute a command using RSH from Solaris...
Author: rohitban Date: 07/22/2010
Consider this scenario: RHEL is working as a NIS Master server. Windows 2008 R2 box is installed...
Author: abhisekbasu Date: 07/02/2010
Recently noticed, that the SUA SDK installation is not going to the desired page to download the...
Author: abhisekbasu Date: 07/02/2010
Recently we got an issue where running ID command on a Windows 2008 was returning a number different...
Author: rohitban Date: 07/02/2010
Recently we got a issue where customer wanted to start/stop windows service using RSH. The operating...
Author: rohitban Date: 06/22/2010
We were working on a case in which we were unable to install NFS components on Windows 2008....
Author: devendra1 Date: 06/22/2010
We do get cases where the User name mapping information is lost after restarting the Server/User...
Author: rohitban Date: 06/18/2010
We were working on a case in which users were unable to mount NFS share from a UNIX machine on a...
Author: devendra1 Date: 06/18/2010
<Previous Next>
Password changes made from AD are not getting synced to Unix for some users
Recently we got a case where Password changes made for domain users were not getting synced to Unix NIS clients. The issue was only happening for couple of users and rests all users' password changes were synced correctly.
To begin with we checked the configuration made on the Windows and UNIX side as per the blog on Psync. Also verified the Unix attributes for the effected users and all seems to be fine.
The environment at the customer's end was: Windows 2003, SFU 3.5 as a DC and Windows 2008 as DC. On Windows 2003, https://support.microsoft.com/kb/921599
was installed. Also the issue was there irrespective of password being changes from Windows 2003 or Windows 2008 DC.
Also to add to the issue, we were getting success information 4098 under the events logs.
So we moved to the Unix box to troubleshoot on this issue. To begin with, confirmed that the Unix was configured correctly as NIS client. We ran the 'ypwhich'
command to confirm the same.
Then I checked the local password file (/etc/passwd) in the Unix box and found that there was a local user also with the same name. Looking at the password file,
we could identify the root cause for the issue.
The reason the user (user1) was having issues login to the client (Unix1) was the presence of a local user with the same name which was conflicting. This is due to the fact that in /etc/nsswitch.conf file, we have an entry for 'passwd' . Now for this entry we specify files first and then NIS. Even if we specify compat, it would look into
the local passwd first. Hence this causes the conflict and the user is not authenticated against the AD.
Removing the user's account locally resolved the issue.
Persistent drive mappings do not work with Client for NFS
Persistent drive mappings do not work with Client for NFS
After SFU 3.5 was shipped, there have been a lot of changes in Windows networking client stack. Some of these changes affected the way persistent drive mappings for NFS shares are handled in Windows and as a result, it doesn't work anymore. Fortunately, there a simpler workarounds for this issue and the development efforts was redirected to improve the Client for NFS component to make it more useful. I will discuss a few of them below –
- Add them as Network Locations – Network locations appear under the Computer along with your disk and CD/DVD drives and are usable by all Windows applications. The only exceptions are the command line applications which do not have a way to access these network locations. To add a network location, follow the steps below –
Open "Computer"
Right click on empty area and select "Add a network location"
Click Next, select "Choose a custom network location" and in the next screen, type the complete UNC path of the NFS share and click Next.
On this screen, type a friendly name and click Finish on the next screen.
Use a scheduled task – you can use a CMD script as a scheduled task in Windows that runs at every logon to map a drive to the NFS share. This can help if you have a requirement to assign a drive letter to a NFS location. Following is what this CMD script should contain –
mount \\nfs-server\nfs-share X:
Create symlink to NFS share – this option works really well on Windows Vista and later. Just run the following command to create a symlink -
mklink /D C:\nfs-link \\nfs-server\nfs-share
Now, every kind of application will be able to access the contents on the NFS share using the path C:\nfs-link.
All of the above are one time operations and can serve the purpose for different scenarios. Drop us a suggestion at dsix [at] microsoft [dot] com, if you have any other suggestions to add to the above.
PrincipalDomain needs to be changed to enable non admin local users to do RSH on member server
Recently we got an issue reported, where non admin local user were unable to do RSH from member server.
Below were our observation based on our testing:
- As per our testing on lab machines, we found that the issue was coming when we were logged in as a non-admin local account
- The error message was message "rcmd: unknown user: localusr".
- Reinstalling SUA SDK on the member server did not resolve the issue
- Also, we were able to do a 'rsh' while logged in as local administrator account
- If we take the machine out of the domain, then the local non admin users had no issue doing 'rsh'
- With, further research, we found that the issue was with the "PrincipalDomain" which was set for SUA
- Running the pdomain command from the korn shell gave the "PrincipalDomain" name. This was set to the domain name on the member server.
- Hence when we were running the command as domain user, rsh was working and local account was failing.
- So, as a first step, we created a user with the same name (as local account) in the domain. Now, we got different error while running the rsh command "Operation not permitted".
- Hence we changed the "PrincipalDomain" which was set for SUA and this resolved the issue.
Steps to change the "PrincipalDomain" forSUA: (Resolution)
- Open regedit
- Browse to the location HKLM\Software\Microsoft\SUA
- Click on new String Value and put the name as PrincipalDomain
- Edit the registry key and put the hostname of the local machine
- Reboot the machine
- Once the box is rebooted, login with the non-admin local account
- Open Korn shell (ksh –l) and run the pdomain command
- It should show the hostname of the machine instead of the domain name.
- Now run the rsh command. This should works.
BTW, making the changes will not affect running rsh command as domain user
Redhat client displays nobody/nobody: Configuring IDMAP.CONF on Redhat to resolve the user/group name in NFS v4.1
Finally we have a good new for the users who are looking to map Redhat users and group with Active directory users while using NFS v4.1 protocol.
As we all know that there are difference in behaviour when compared we NFS v4.1 to NFS v3. One of the key difference (mention below) was the way Windows was sending the response to the Unix.
- With NFS v3, we are following the NFS RFC and sending the uidNumber/gidNumber for the users and group and hence the Linux client is able to resolve it.
- With NFS v4.1, we are also following the new RFC and sending the input as user>@<domain ( fattr4_owner_group).
Now consider a scenario, where user mapping is configured through Adlookup (Active directory lookup). With NFS v3, once the mapping configuration is configured and proper NTFS permission is in place the user/group name are resolved correctly on both Windows and UNIX.
But with NFS v4.1, though everything is in place, but Windows would be sending the response in different format. Windows would be sending user@domain instead of the uid for the user and gid for the group. Hence the Unix machine are unable to resolve this response and displays
nobody/nobody when the file permission are listed.
From the windows side, if we run the nfsfile command, the correct user/group name are resolved and displayed.
Due to this there were lot of customer request coming in to fix this. But as Windows was following the NFS RFC for version 4.1, there was nothing much to be configured on the windows side. Based on our research, the configuration needed to be done on the Unix (Redhat for this scenario) side.
To fix the settings on the Redhat side, we started with our research. We observed the below from the logs collected:
From /var/log/messages on Redhat:
- my-unix nfsidmap[]: nss_getpwnam: name 'testuser5@contoso' does not map into domain 'contoso.COM'
- my-unix rpc.idmapd[]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch
From the netmon trace, we could see that Windows is send the GetATTR response back to the Redhat in the format (user@domain).
Then we started looking into the idmap.conf file and found the entry below:
Your local schema's attribute name to be used for NFSv4 user names (Default: NFSv4Name)
NFSv4_uid_attr
We were not sure, if this is causing the issue. Then we configured Kerberos as with NFS v 4.1 the server and client need to agree on the concepts like domain and realms. And eventually that also requires idmap configuration on the client side.
Then based on further research we were able to fix get the right settings needed to fix the issue. In the below example we have taken the following environment:
Environment:
- Windows 2012 as member server , Server for NFS
- Redhat 6.1 as NFS client
- Windows 2008 R2 as DC
Steps:
- No Kerberos required to be configured on Redhat side
- Adlookup configured on Windows side for user/group mapping
- Username has to be same across Windows and Linux
- In the idmap.conf file we just need to add NetBios name of the domain ( as we are passing the inputs from NFS server as user@domain)
a. Domain = contoso
Note: Restarting the idmapd daemon through the NFS services will not fix the issue. You would need to reboot the Linux machine so that it recreates/ rereads the below : ( /usr/lib64/libnfsidmap/nsswitch.so)
Once done, we were able to user/group names on both the windows and Unix side.
Restrictchown not working on a Cluster environment
Recently we got a case where the customer was trying to enable the Unix client to change the ownership of file and folders on a NFS
share hosted on a cluster resource. We can achieve this by modifying the below registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerForNfs\CurrentVersion\Exports\<No>/Restrictchown ; (where <No> refers to the NFS share no.) assigned to 0 and restart the NFS Service.
This works fine on a standalone system. But in a cluster environment this registry key is only available when the resource is online. If
we change the value to 0; the test from UNIX machine shows it is not effective. So, we attempt to take the resource offline and bring it back. This causes the registry to get the default value 1.
Also, we tried to fallback to other node (instead of taking it offline); however on the second node this registry is created with the value
of default value of 1.
With more research we found that the configuration information for cluster shares are mastered on the cluster resource properties
for the share. They are copied from there to the normal registry just while the share is present on the node and then deleted afterwards.
With testing we saw that the Restrictchown properties are displayed under the private properties of the cluster resource.
For example:
C:\>cluster resource NFS-Resource /privproperties
Listing private properties for
'NFS-Resource':
T Resource Name Value
--
-------------------- ------------------------------ -----------------------
S NFS-Resource ShareName NFS-Resource
S NFS-Resource Path s:\NFS-Resource
D NFS-Resource ShareSubDirs 0 (0x0)
S NFS-Resource PermissionsV2
D NFS-Resource GlobalPermV2 10 (0xa)
D NFS-Resource AnonymousAccessAllowed 1 (0x1)
L NFS-Resource UnmappedUID -2 (0xfffffffe)
L NFS-Resource UnmappedGID -2 (0xfffffffe)
D NFS-Resource Encoding 7 (0x7)
D NFS-Resource SecurityFlavor 2 (0x2)
D NFS-Resource RestrictChown 0 (0x0)
D NFS-Resource SymbolicLinks 1 (0x1)
D NFS-Resource TruncateNames 0 (0x0)
The command below will force the desired behavior:
- cluster resource <NFS-Resource> /privproperties RestrictChown=0
RHEL clients displays Anonymous UID and GID in the permission for the files and folder that are shared over NFS v4.1
Consider a scenario where Windows 2012 is hosting shares over NFS v4.1. Adlookup is configured for user and group mapping. RHEL 5.8 is the NFS client which is mounting the NFS shares and then accessing as a mapped user.
From the Windows side correct information is displayed on the ownership tab. Also the user who is owning the share is a mapped user. But from the Linux side, we see anonymous UID and GID when we list the permission.
Explanation: The NFS server is supposed to return "<user>@<domain>" according to the RFC to the Linux NFS client. Though the RFC also allows "<numeric_uid>" if there is no string user name. For example, on our NFS v4 server, if you are using UUUA rather than a mapping solution then we return a numeric string version of the UID and GID. Also by parallel user, does the customer means same user name. In our test environment even if the user names is same then also it shows nobody. We have not tried, but may be configuring Kerberos on the Linux side may be able to resolve the user name. In NFS v4 – the server and client need to agree on the concepts like domain and realms. That requires idmap configuration on the client side.
Hence we need a configuration on the client side to translate from the OWNER and OWNER_GROUP strings in the replies from the server. These are going to take the form <account>@<domain>. Without such information, the client is not going to be able to interpret the OWNER and OWNER_GROUP attributes returned by the server.
Popular posts from this blog
Windows Azure：新计划程序服务，读取访问同步冗余存储以及监测更新 [原文发表地址] Windows Azure: New Scheduler Service, Read-Access Geo Redundant Storage, and Monitoring Updates [原文发表时间] December 12, 2013 12:41 PM 今天早上我们推出了windows Azure的另一组增强功能。今天的新功能包括： 程序调度：新的windows Azure计划程序服务 存储：新的同步读写冗余存储方案 监测：windows Azure服务的监测及诊断的增强功能 所有的这些改进现在都可以使用（注意有些功能仍然是在预览）。下面是有关他们的更多详细信息： 程序调度：新的windows Azure计划程序服务 我很高兴宣布我们可以预览新的Windows Azure调度服务。Windows Azure调度服务允许你安排启用HTTP/S端点的任务或者按你制定的任何计划向存储队列上发送信息。使用调度程序，你可以创建可靠的调用Windows Azure内部或外部服务的任务并且按照常规计划立刻运行或者设置他们在未来某刻运行。 想要开始使用调度程序，首先你需要在 Windows Azure Preview 页面上为预览进行注册。一旦在预览页中注册成功后，你可以登陆到管理门户并且开始使用它。 创建一个调度任务 一旦你在你的订阅中启用调度预览，你可以用以下几个简短步骤很容易的创建一个新的任务。 在Windows Azure门户管理网站内单击 新建-> 服务程序 -> 调度 –> 自定义创建： 选择一个你想要运行任务的Windows Azure 区域，之后选择一个已有的任务收集器或者创建一个新的并把任务加进去： 之后你就能定义你的任务操作。在本例中，我们会创建一个向web站点发送GET 请求的HTTP 操作（你也可以使用其他的HTTP协议，像HTTPS）。 对于处理长时间的请求或者在脱机状态启用某项服务，你也许更期望给存储队列添加一些信息而不是坚持启用一个Web 服务。要给存储队列添加信息你只需要选择存储队列作为你的操作，之后创建或选择一个存储帐号及队列用来发送请求： 一旦你定义了你要
AD RMS to AD RMS to Azure Information Protection Part 1 The Scenario: So, you have read my previous blog posts about AD RMS side-by-side migration and Enterprise Migration from AD RMS to AIP using SCCM but unfortunately both of those articles assume best case scenario for the original AD RMS cluster. Sadly, that is not always the way things work. In the real world, the AD RMS instance may have been initially installed on Windows Server 2003 using RMS 1.0 and was subsequently upgraded to 2008 R2 keeping all of the settings pretty much the same. This usually means using http only and having no CNAMEs for AD RMS or SQL. This makes my happy articles on upgrading to newer versions of AD RMS or to AIP a lot less straightforward. Let's fix that. The Setup: Luckily, most of the concepts for migration are the same as what I documented in the previous two articles, so I am going to happily plagerize reuse the content in those articles to make something new. This a
SQL Server 2008 R2 Feature Pack is now available https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52 This includes SQL Server Native Client 2008 R2. SQL Server code-named "Denali" Native Client supporting ODBC 3.8 We're excited to announce that Denali SNAC CTP1 adds support for the ODBC 3.8 features of the Microsoft ODBC DM (Driver Manager) introduced in Windows 7 and Windows Server 2008 R2. Please refer to https://blogs.msdn.com/b/data/archive/2009/07/06/odbc-dm-3-80-in-windows-7-and-windows-server-2008-r2.aspx for a blog posting detailing the ODBC DM changes. The ODBC 3.8 features supported in Denali SNAC are: Streamed Output Parameters Support retrieving output parameters in parts via SQLGetData when the output parameter was bound using SQLBindParameter . This is extremely valuable when working with large data objects, such as varbinary(max), varcha
Comments
Post a Comment