I recently came across a scenario where a 4 TB Western Digital (WD) ShareSpace which functions as a NAS had to be used to data storage. I updated the NAS firmware with the latest build and was ready to get going. But easy things sometimes become more complicated and confusing.
So when I accessed the NAS Device from the Network it prompted me with the error message “No Process is on the other end of the Pipe“. I immediately started to Google around for some quick fix and I some articles which were trying to nail the issue.
I was unable to solve the issue using any of the recommended solutions. But from the articles, I came to understand that the issue was primarily because of the Domain Controller being Windows Server 2008 R2. So there comes the question – What difference does Windows Server 2008 and Windows Server 2008 R2 make with regards to authentication. The difference is that the newer Operating Systems use Kerberos for authentication. For Kerberos to function properly and the logon to work, the Service Principal Names (SPNs) have to be accurate and updated.
I tracked down the issue by browsing the Active Directory Users & Computers (ADUC) console and navigating to the Computer Object that was created by the WD ShareSpace NAS when it was joined to the Domain . In the Attribute Editor tab, I found the below two AD attributes were misconfigured: dNSHostName and servicePrincipalName.
Attribute Name: dNSHostName, Attribute Value = DeviceName.DomainName (NAS01.CONTOSO.COM)
Attribute Name: servicePrincipalName, Attribute Value = HOST/DeviceName; HOST/DeviceName.DomainName (HOST/NAS01;HOST/NAS01.CONTOSO.COM)
When the above two attributes were replaced with the right values, the NAS device became accessible. But what I noticed was that once the NAS device was restarted, the attributes were restored back to their original values and the access to the NAS device stopped. After the restart the default DNSName localhost.localdomain was getting restored on the relevant Computer object of the NAS.
This attribute was getting reflected from the hosts file present in the WD ShareSpace Unix OS \etc\hosts file. So I decided to modify the hosts file. To access the Unix shell of the WD NAS Device, we first have to enable SSH access and then access the NAS device using a software like Putty.
On successful connection, you will be prompted to authenticate to the NAS Device. Here you have to use the default credentials of the WD NAS Device. The default username is root and the password is welc0me. After successful login, navigate to \etc directory (cd \etc) and then open the hosts file using the vi editor (vi hosts). Insert (Press i at the point where data has to be inserted) the NAS FQDN name in the \etc\hosts file and when done exit the editor by saving the file (ESC+:w+Enter).
Another thing to verify is that the DNS has an A record for DeviceName.DomainName (NAS01.CONTOSO.COM) which is mapped to the IP Address of the NAS. Also ensure that no duplicate DNS entries (A Records) exist – and if they do exist, delete all except the valid one.
Once the above changes are verified, NAS Device will be accessible without any issue and the error will disappear automatically. But after all the configuration hassles, you will be surprised to know that this device does not support granular NTFS permissions. If anybody was able to achieve the granular security using WD Sharespace then do share the procedure with us.