Chuck Lever <chuck.lever@xxxxxxxxxx> writes: > On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote: >> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote: >>> "J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: >>> >>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, Aníbal Monsalve Salazar >>>> wrote: >>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote: >>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having >>>>>> issues accessing my kernel.org account so for the moment the >>>>>> tar ball is only available on SourceForge: >>>>>> >>>>>> http://sourceforge.net/projects/nfs >>>>>> [...] >>>>> >>>>> 1.1.3 clients don't work with a 1.0.10 server anymore. >>>> >>>> Very weird--it might make sense if upgrading nfs-utils broke the >>>> mount >>>> itself, but here it seems the mount is succeeding and subsequent >>>> file >>>> access (which I'd expect to only involve the in-kernel client >>>> code) is >>>> failing. Maybe there's some difference in the mount options? >>>> What does >>>> /proc/self/mounts say? I assume these are all v2 or v3 mounts? >>> >>> I discovered today that I was no longer able to write to the v3 >>> mount on >>> my 1.1.2 server. I checked /proc/mounts and noticed sec=null on the >>> mount. Either adding sec=sys to the client's mount options or >>> downgrading to nfs-common 1.1.2 on the client fixes the problem. >> >> That would do it! >> >> So it sounds like there's a bug that causes mount.nfs to get the >> default >> mount options wrong? > > I'm not sure I'm following this. I can't think of a user-space > mount.nfs change in 1.1.3 that would affect the sec= option. > > Paul, which kernel are you running on your clients? Either 2.6.26 or 2.6.27-rc1+. I'll double-check. Whichever one it was, the problem was present with 1.1.3 installed, and not present with 1.1.2 installed. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
