On Fri, Nov 13, 2009 at 03:05:08PM +0100, Thomas Gebhardt wrote: > Dear Herbert, > > IMHO the chdir happens _before_ the --bind mount should > > be affective, maybe you mounted it already there or > > you have a problem with the barrier flag (note that > > the debian 2.6.26 branch is broken and requires manual > > fixes to all the attribute flags when switching to or > > from such a kernel), besides that, I'd suggest to get > > a more recent util-vserver snapshot ... > ok, I changed linux-image-2.6.31.5-vs2.3.0.36.23-beng and > util-vserver-basic-debian_0.30.216-pre2849 (which were advertised > on this list recently), but that didn't change anything. > > things which might work: > > - you can do the bind mount before the the guest is > > started (either permanently or via one of the > > guest start scripts) and exclude the path from the > > namespace cleanup > > - you could put the actual nfs mount in the guest's > > fstab.remote, as long as mounting itself can happen > I tried these alternatives with "various" success: sometimes > it worked, then suddenly it ceased to work. By sniffing the > network traffic I noticed that the ip source address of the > nfs requests changed from the vserver ip to the host ip > some minutes after the vserver was started. This seems to be > the reason for my permission problems. > I also tried to mount the nfs share within the > vserver manually (with SYS_ADMIN, SECURE_MOUNT, BINARY_MOUNT > [b|c]capabilities enabled): > mount -t nfs nfsserver:/home /home > but the source ip address of the resulting nfs traffic was > the host(!) address, not the vserver address. > It might be worth to mention that the ip address of the vserver > is bound to a vlan device while the host ip runs on native eth0. > I can't see that this fact is of any influence for the flaw, however okay, I guess we need more details about your setup, specifically the nfs part (server, client, versions) and of course, somebody to help with testing .... best, Herbert > Thanks, Thomas