| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
SFU 3.5 *hotfixed* NFS client won't use reserved ports?
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 SFU 3.5 *hotfixed* NFS client won't use reserved ports? - Apr. 12, '06, 12:39:38 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
Ack! I thought I'd try applying hotfixes to SFU to see if it would improve NFS responsiveness, and now I can't mount NFS drives at all! On the server, I see the error 'mount request from <host> from unprivileged port'.
Previously when I was having this problem, the issue was that the NFS client isn't sticking to ports 0-1023 to talk to the NFS server, and the solution was to create the DWORD registry key 'HKLM\SOFTWARE\Microsoft\Client for NFS\CurrentVersion\Default\UseReservedPorts' with a value of '1'. However, it isn't working this time  !
Am I missing something, or am I stuck using the non-hotfix'd NFS client?
I have hotfixes 883520-2kxp, 886655, 887531, 894186, 902074, 904358, 904838 and 904838 applied. 'fileinfo' reports:
/dev/fs/C/WINNT/system32/PSXSS.EXE 8.0.1969.36
/dev/fs/C/WINNT/system32/PSXDLL.DLL 8.0.1969.36
/dev/fs/C/WINNT/system32/POSIX.EXE 8.0.1969.36
/dev/fs/C/WINNT/system32/PSXRUN.EXE 8.0.1969.36
/dev/fs/C/WINNT/system32/drivers/PSXDRV.SYS 8.0.1969.1
< Message edited by woehlkmp -- Apr. 12, '06, 1:24:28 PM >
|
|
|
|
|
RE: SFU 3.5 *hotfixed* NFS client won't use reserved po... - Apr. 12, '06, 2:19:07 PM
|
|
|
Rodney
Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Fileinfo only reports on the Interix "jewel" files.
And these files have nothing to do with NFS (the NFS is abstracted
away from Interix via the normal file system calls).
894186 is the most recent NFS hotfix. So that's the one of concern in your list.
I'll assume you've tried rebooting a couple of time (age olde Windows favorite).
Try rolling this hotfix back out and then reinstalling it making sure by hand that
you have no NFS connections (in or out) before re-installing. Just an idea.
To be sure the hotfix is applied you'll want to popup the properties box on
the NFS driver file and look at the version information.
|
|
|
|
|
RE: SFU 3.5 *hotfixed* NFS client won't use reserved po... - Apr. 12, '06, 3:07:11 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
> Fileinfo only reports on the Interix "jewel" files.
...which is exactly why I listed what hotfixes I had applied and supplied a link that gives version numbers for the files these affect.
Actually, 904838 is the most recent NFS hotfix, providing 8.0.1969.37 of nfsrdr.sys.
I did try rebooting after changing the registry key; no dice. Next I tried removing 904838 (leaving me with 8.0.1969.27 of nfsrdr.sys) and rebooting; again, no joy. So... I removed 894186 as well. It works now (no surprise there, as I'm back to the original version), but now I'm stuck with the slow performance I was hoping to fix.
Does you (or does anyone) know if the hotfix'd version of nfsrdr.sys just doesn't support only using ports 0-1023, or do I simply have the wrong registry key to tell it to do so? I'm hoping it's the latter!
< Message edited by woehlkmp -- Apr. 12, '06, 5:32:39 PM >
|
|
|
|
|
RE: SFU 3.5 *hotfixed* NFS client won't use reserved po... - Apr. 12, '06, 4:55:50 PM
|
|
|
Rodney
Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
HKLM\Software\Microsoft\Client for NFS\CurrentVersion\Default\UseReservedPorts (DWORD)
is supposed to be the correct registry location. I can't see this functionality
being removed. It was specifically put in for working with other systems.
The hotfixes are cumlative. So 904838 shouldn't need 894186 before it.
Try just 904838 alone?
|
|
|
|
|
RE: SFU 3.5 *hotfixed* NFS client won't use reserved po... - Apr. 12, '06, 5:36:08 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
> I can't see this functionality being removed.
It wouldn't actually be "removed", since as I understand, nfsrdr.sys (version 8.0.1969.1 to whenever it was changed) just worked this way and no other way; thus having this key would be superfluous. I think what happened is at some point, the client changed to be like the SUA client (that is, use any port including 1024+), but the code to check this key was not added when that happened.
Installing 904838 without 894186 didn't work any better, not that I expected it to (still the same nfsrdr.sys).
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
