"Network Error 53", "The data area passed to a system call is too small" or "Unknown Error"


“Network Error 53”, “The data area passed to a system call is too small” or “Unknown Error”


Client for NFS included with Windows Server 2003 R2 returns different errors when trying to access NFS shares on UNIX-based NFS servers. The exact error message may depend on your environment – you might get one or more from the ones mentioned above. And, at the same time, SFU 3.5 Client for NFS may work just fine.


Analyzing the network traffic may show MOUNT or NFS calls being “rejected for security reasons (5)”.


The R2 Client for NFS uses high ports (>1024) to connect to NFS servers and that’s known to cause the above errors. There are two ways to fix this –




    • Change how your NFS servers export the NFS shares and make them allow connections from high ports, or,

    • Add UseReservedPorts DWORD value under HKLM\Software\Microsoft\Client for NFS\CurrentVersion\Default and set it to 1. Restart the Client for NFS service to allow the change to take effect.

Should you worry about security when you change your NFS server to allow connection from high ports? The answer is NO. An excerpt from RFC2623 says so –




Many NFS servers will require that the client send its NFS requests
from UDP or TCP source ports with values < 1024. The theory is that
binding to ports < 1024 is a privileged operation on the client, and
so the client is enforcing file access permissions on its end. The
theory breaks down because:


*    On many operating systems, there are no constraints on what port
     what user can bind to.
*    Just because the client host enforces the privilege on binding
     to ports < 1024 does not necessarily mean that a non-privileged
     user cannot gain access to the port binding privilege. For
     example with a single-user desk-top host running a UNIX
     operating system, the user may have knowledge of the root user
     password. And even if he does not have that knowledge, with
     physical access to the desk-top machine, root privileges are
     trivially acquired.


On the other hand, turning off low ports check on the NFS servers ensures compatibility with NFS clients irrespective of clients using high or low ports to access the NFS servers.


Note that above mentioned errors can be caused by number of other factors as well so if the solutions mentioned above don’t work for you – focus your troubleshooting on other aspects.

Comments (14)

  1. yifli says:

    I installed NFS client and user name mapping on a windows 2003 server R2 EE (x64) with sp2.

    I can see the NFS shares exported by a NFS server (running Linux) using ‘showmount’

    But when I try to mount the shares, I always get ‘Network Error 53′ when I am using command line or ”The drive could not be mapped because no network was found’ when I am using GUI. However, I don’t have any problems with mounting a windows share.

    I did follow your instructions to add ‘UseReservedPorts’ to registry, but it did not help.

    I can mount the same directory from a windows 2003 server EE with sp1.

    Can you help me out? thanks

  2. sfu says:

    I guess the problem lies somewhere else.

    Did you try the mount command?

    Please use the Email link in the side bar of this blog and send me a network trace while you are trying to mount the shares using the mount command.

  3. yifli says:

    BTW,  our network is like this:

    windows network is a private LAN (192.168.x.x) and we have a router for the windows network to connect to outside.   The NFS server is a remote server.

  4. yifli says:

    While I was trying mount command, I used Microsoft network monitor to trace the network traffic

    And I saw some RPC frames to which network monitor gives a description of ‘Unknown Message Type’.

    BTW, is there a way I can send you a file attachment?

  5. sfu says:

    Yes, On this page, there’s a "Email" link in the "This Blog" section under the "Search" box.

    Send me a mail and I’ll get back to you.

  6. yifli says:

    Thank you for the reply

    But there’s no way for me to attach a file.

    What I want to do is to send you a *.cap file generated by Network Monitor.   I can only type text message there.

  7. sfu says:

    Right, send me a mail, I’ll reply using my email ID and then you can send me the attachment.

    Publishing my email ID will attract spam and that’s what I want to avoid.

    I hope you understand my concern.

  8. yifli says:

    thanks.

    My friend told me how I should reach you through email.

    I just sent you a email.

  9. R2 says:

    I’m very much sorry, please remove my old comment.

    But then I got an error like "system has insufficient resources to complete your request". And this is on a clean windows installation on a 8G RAM box… So I had to reboot and things are working now.

    Thanks for your article!

  10. Stephen says:

    This does not appear to work for XP which has the same problem for me.

    Nov 10 18:59:42 m25lnx1 mountd[4038]: refused mount request from 10.0.0.1 for /home (/home): illegal port 1378

  11. sfu says:

    This issue occurs because hot fixes later than KB894186 change the client to use higher ports. Are you running any fix newer than that? If yes, you need to add insecure option on the export to get this to work.

    Insecure option is not really insecure as I mentioned in the above post so I hope this wouldn’t be a big issue.

    – Ashish

  12. evo says:

    I'm havving the same problem yifli had right out of the box. As this problem been rectified ?

    Thanks

  13. sfu says:

    @evo – I don't have the emails that I exchanged with yifli now. Did you try adding insecure option on the server side? Drop me an email using the form at blogs.msdn.com/…/contact.aspx.

  14. Rick says:

    Here's my "formula" for getting NFS on Linux working with Windows 7 Client for NFS.  It opens up some holes (like firewalls), but gets you up and running and then you can lock things back down from there.

    Enjoy!

    Rick

    P.S.  I decided to post this after burning about 6 hours figuring all this out… (very frustrating – maybe I can also find this post next time I need it 🙂

    NFS configuration:

    On CentOS (or other Linux variant):

    —————–

    Add to /etc/exports:

    /devpool 192.168.0.0/16(rw,sync)

    exportfs -a

       service nfs restart

    Disable CentOS Firewall (or program in all ports required for portmap and other services to support NFSv4 across firewall!)

    On Windows 7:  (You must be running Ultimate or Pro, a Windows 7 which supports Client for NFS)

    Install "Client for NFS" feature (Control Panel / Programs and Features / Services for NFS / Client for NFS)

    Disable Windows Firewall or other local firewall (open all required ports later)

    Use "Regedit" and add anonymous UID and GID to 500,500 (or whatever user ID you want to have access on CentOS)

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftClientForNFSCurrentVersionDefaultAnonymousGid  (new DWORD 32)

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftClientForNFSCurrentVersionDefaultAnonymousUid  (new DWORD 32)

    – Reboot (or restart NFS Client from CMD line)

    nfsadmin client stop

    nfsadmin client start

    If you get Error 53, the you must change the Network Priority order so that Client for NFS network provider is ABOVE the regular Windows Network provider (so NFS gets tried first; otherwise, you'll get prompted when trying to make connections and get Error 53, which will waste a LOT of your time as it did mine):

    answers.microsoft.com/…/49acc0b0-89e5-4ee0-b30f-a8fe26e8f367

    (then reboot)

    mount -o anon 192.168.146.131:/devpool V:

    Celebrate!