Bug 125996 - NFS should support NLM_MAXCOOKIELEN != 8 to work with OSX, BSD, etc
Summary: NFS should support NLM_MAXCOOKIELEN != 8 to work with OSX, BSD, etc
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Brian Brock
URL: http://www.fys.uio.no/~trondmy/src/Li...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-14 23:24 UTC by Damian Menscher
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-12-20 20:55:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:550 0 normal SHIPPED_LIVE Updated kernel packages available for Red Hat Enterprise Linux 3 Update 4 2004-12-20 05:00:00 UTC

Description Damian Menscher 2004-06-14 23:24:16 UTC
Description of problem:
NFS deals with cookies, which are typically, but not always, 8 bytes. 
 Linux had the 8-byte limit hard-coded in, which means we can't serve 
NFS to certain client OSes, such as OSX and fBSD.

There's a patch available at

http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.
23-03-fix_osx.dif

which resolves the problem.  It's been stable for me under RH9 and 
RHEL3 (I recompile the RPMs with this patch added), but it would be 
great to get this into the official release.


Version-Release number of selected component (if applicable):
kernel-smp-2.4.21-15.EL

How reproducible:
Always

Steps to Reproduce:
1.  Try serving NFS to an OSX or fBSD client

Comment 1 Damian Menscher 2004-08-04 19:31:01 UTC
Changing severity from "enhancement" to "normal" since a functional 
NFSd is something to be expected.

[rant]There have been three kernel updates since I submitted this 
report.  It would be nice if someone could take the 2 minutes to 
apply the patch.[/rant]

Comment 2 Steve Dickson 2004-08-11 15:41:13 UTC
That's my fault.... Some how it slipped through the proverbial
cracks.... since this made into upstream I've turned everthing
on high to make sure this make the next update....



Comment 3 Tom "spot" Callaway 2004-08-22 17:48:20 UTC
Steve, is this fix liable to make it in U3?

Comment 4 Ernie Petrides 2004-08-23 14:58:33 UTC
Tom, no.  U3 closed a few weeks ago.


Comment 5 Ernie Petrides 2004-09-28 08:46:40 UTC
A fix for this problem has just been committed to the RHEL3 U4
patch pool this evening (in kernel version 2.4.21-20.12.EL).


Comment 6 Damian Menscher 2004-09-28 15:40:20 UTC
Thank you!

Does this mean it will make it into security updates released before
U4, or will we have to keep recompiling until after U4?

Comment 7 Ernie Petrides 2004-09-29 02:11:01 UTC
There is no intention to include this fix in any possible security
update before u4 is released.


Comment 8 John Flanagan 2004-12-20 20:55:20 UTC
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-550.html



Note You need to log in before you can comment on or make changes to this bug.