Hello. I am using nfsv4 in etch, and experienced the same problem. The
workaround you say solves it, but I am afraid an update overwrites nfs-common,
and then the workaround is lost.
So, could it be possible that this bug get also fixed in etch?
Thank you very much.
___
On Mon, Jul 14, 2008 at 12:46:19PM +0400, Alexandra N. Kossovsky wrote:
> The only thing I do not understand is why you cannot reproduce it. Have
> you tried?
My options for actually testing this is rather limited -- I only run NFSv4
one place, and it's in production. The limited testing I am able
On Fri, Jul 11, 2008 at 11:19:53PM +0200, Steinar H. Gunderson wrote:
> On Fri, Jul 11, 2008 at 09:48:05PM +0400, Alexandra N. Kossovsky wrote:
> > Feel free to ask me for more info.
>
> OK, this sounds like an upstream bug. I guess you will have more luck
> contacting them; I cannot reproduce thi
On Fri, Jul 11, 2008 at 09:48:05PM +0400, Alexandra N. Kossovsky wrote:
> Feel free to ask me for more info.
OK, this sounds like an upstream bug. I guess you will have more luck
contacting them; I cannot reproduce this, and I haven't seen any bug reports
saying the same thing either, so this is p
On Fri, Jul 11, 2008 at 06:37:01PM +0200, Steinar H. Gunderson wrote:
> On Fri, Jul 11, 2008 at 06:53:55PM +0400, Alexandra N. Kossovsky wrote:
> >> One of the first things that happen in /etc/init.d/nfs-kernel-server is a
> >> modprobe of nfsd... Do you have an /etc/exports at all?
> > Yes I do.
>
On Fri, Jul 11, 2008 at 06:53:55PM +0400, Alexandra N. Kossovsky wrote:
>> One of the first things that happen in /etc/init.d/nfs-kernel-server is a
>> modprobe of nfsd... Do you have an /etc/exports at all?
> Yes I do.
> /etc/init.d/nfs-common is started at /etc/rcS.d/S44nfs-common, while
> nfs-ke
On Fri, Jul 11, 2008 at 02:52:32PM +0200, Steinar H. Gunderson wrote:
> On Fri, Jul 11, 2008 at 01:41:35PM +0400, Alexandra N. Kossovsky wrote:
> > I've found better workaround: "modprobe nfsd" in /etc/init.d/nfs-common
> > before start of idmapd solves the problem. Also, the problem is solved
> >
On Fri, Jul 11, 2008 at 01:41:35PM +0400, Alexandra N. Kossovsky wrote:
> I've found better workaround: "modprobe nfsd" in /etc/init.d/nfs-common
> before start of idmapd solves the problem. Also, the problem is solved
> by adding "nfsd" to /etc/modules. I have not try this workaround
> with etch
On Thu, Jul 10, 2008 at 08:17:21PM +0200, Steinar H. Gunderson wrote:
> On Thu, Jul 10, 2008 at 07:15:45PM +0400, Alexandra N. Kossovsky wrote:
> > The same problem exists with etch; I've just added the 2 lines above to
> > the end of /etc/init.d/nfs-kernel-server. However, I'd like to see the
> >
On Thu, Jul 10, 2008 at 08:17:21PM +0200, Steinar H. Gunderson wrote:
> Well, I guess the big question is: What happens on startup -- does it try to
> start idmapd at all?
Yes, obviously. I see this start in the logs and, additionally, idmapd
works for for _client_ nfs4 (i.e. volumes mounted from
On Thu, Jul 10, 2008 at 07:15:45PM +0400, Alexandra N. Kossovsky wrote:
> The same problem exists with etch; I've just added the 2 lines above to
> the end of /etc/init.d/nfs-kernel-server. However, I'd like to see the
> problem really fixed in lenny.
Well, I guess the big question is: What happe
Package: nfs-common
Version: 1:1.1.2-4
Severity: important
I have a lenny machine which is at the same time nfs4 server and nfs4
client. All nfs4 servers/clients use nsswitch translation method.
After reboot, I see mounted nsf4 files with correct owners;
however, my clients see my exported files
12 matches
Mail list logo
