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 Thanks, Thomas