I powered on my fileserver tonight because I needed to archive some things from a dieing drive on my main machine. Since I had unmapped my network drive before, I had to re-map it. Should have been a simple process. Unfortunately that wasn’t the case. Turns out, the share had previously been mounted with CIFS (samba), because I had configured that on the server in addition to NFS, and Windows was defaulting to the former. On top of that, I was getting an error from the mount command after fixing the first problem! Good ol’ Windows…
I was able to mount the drive successfully, but I no longer had write permissions. That was when I realized I was accessing a samba share instead of an NFS one. So, I disabled samba, and re-exported the NFS share, including restarting NFS and rebooting the desktop machine. That resulted in the error in the screenshot up top.
Let me first start out by saying that I’m not running on a domain, so this wasn’t a simple case of mapping issues from a user mapping server or from AD.
So I checked google. There were a number of different solutions posted. I tried them all in the order of what seemed to be most likely, to what seemed to be least likely.
First, I checked permissions of the share on the server. Those were fine. So, I switched the network provider order in Windows, moving NFS all the way to the top, and rebooted. No good. Then, I added the AnonymousUid and AnonymousGid entries to the registry with values of 0, and rebooted again. No good either. Finally, rather than reboot several more times, I disabled Windows Firewall completely, added the insecure option to the NFS export entries on the server, turned off iptables (even though the port mappings were correctly setup in /etc/sysconfig/nfs and the ports were explicitly opened in iptables), and rebooted Windows once more.
After I did that, it mounted and I had full write permissions again.
I’ve since re-enabled iptables, and Windows Firewall, and things are working fine. I’m not going to go into the trouble of messing with the provider orders or removing the AnonymousUid and AnonymousGid keys just yet, but I strongly believe it would work even after those are reverted, leading me to believe that the fix which solved the problem for me was to enable the insecure flag in /etc/exports. Once I do get around to it, if things still work as they should, I’ll make an update to this post.