Do you have a question or two about SFU, click here to mail me.

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

Published 05 June 07 12:51 AM | Ashish 

"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.

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# yifli said on August 13, 2007 3:07 PM:

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

# Ashish said on August 13, 2007 3:18 PM:

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.

# yifli said on August 14, 2007 10:00 AM:

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.

# yifli said on August 14, 2007 10:03 AM:

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?

# Ashish said on August 14, 2007 10:26 AM:

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.

# yifli said on August 14, 2007 10:47 AM:

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.

# Ashish said on August 14, 2007 11:03 AM:

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.

# yifli said on August 14, 2007 12:01 PM:

thanks.

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

I just sent you a email.

# R2 said on December 7, 2007 4:52 AM:

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!

# Stephen said on November 10, 2008 3:12 AM:

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

# Ashish said on November 11, 2008 3:17 PM:

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

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required

Search

This Blog

Latest NFS hot fix for R2

Latest NFS hot fix for SFU 3.5

Syndication

Page view tracker