Re: Linux 3.7 + Sun solaris 10: Problems when reading dir from application

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 05, 2013 at 08:27:40AM +0200, Harald Dunkel wrote:
> Hi Ulrich,
> 
> On Mon, 4 Feb 2013 21:24:08 +0100
> Ulrich Gemkow <ulrich.gemkow@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > Hello,
> > 
> > please allow a followup of my own on this:
> > 
> > On Monday 04 February 2013 11:12:03 Ulrich Gemkow wrote:
> > > Hello,
> > > 
> > > we upgraded our fileserver from Linux 3.2 to linux 3.7.6 and now have
> > > problems when accessing our nfs-mounted user homes from some sun-
> > > applications (i.e. Adobe Framemaker):
> > > 
> > > In the applications file open box, no files are displayed. When entering
> > > the filename by path, the file can be opened. So it seems some kind of
> > > dir enumeration which is used by the sun applications is broken.
> > > 
> > > Other programs on the sun like ls work as before and show all files.
> > > 
> > > We are using NFSv3 (and cannot switch to v4). Our sun is a very old
> > > machine running Sun Solaris 10.
> > 
> > When mounting with vers=2 on the sun (using NFSv2) the files
> > "reappear", so this is a clear regression in NFSv3 between
> > Linux 3.2 and Linux 3.7.

And the *only* thing you change is the kernel version, not nfs-utils or
anything else in userspace?

> Have you considered upgrading your Solaris version? I had tons 
> of problems with NFS on Solaris10u6 and 10u8, including unresponsive
> mount points, problems with delegations (esp. in the users' .ssh
> directories and .Xauthority files) and strange "permission 
> denied" error messages for some ACL feature I never configured on 
> the server. 
> 
> NFS in Solaris 10u10 works much better together with Linux. I
> haven't tried Solaris 11.
> 
> My servers run Squeeze and the Linux kernel from the squeeze-
> backports repository (3.2.0-0.bpo.4-amd64).
> 
> > Maybe this can be fixed. I will be happy to give more info
> > if someone is interested.

Most interesting would probably be packet captures in both the "good"
and "bad" cases; so, something like:

	tcpdump -s0 -wtmp.pcap

then reproduce the problem, then kill tcpdump and send tmp.pcap.

(And/or take a look at it yourself with "wireshark tmp.pcap", and there
may be something obvious that jumps out even to a non-expert.)

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




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux