Herbert Poetzl wrote: > On Thu, Sep 06, 2007 at 06:11:27PM -0700, Dallas Kashuba wrote: >> We have several vserver guests NFS mounting volumes being served from >> Network Appliance filers. The NFS mounting works as expected, other >> than access to the snapshots provided by the NetApp filesystem. > > NFS tasgging is disabled, I presume? > >> Under normal circumstances (non-vserver), you access the snapshot >> from anywhere along the filesystem by simply doing 'cd .snapshot'. >> Within there you will see a directory for each snapshot named >> something like hourly.0, nightly.0, or weekly.1 (etc), which contain >> copies of the files from those points in time. They work like any >> other directory aside from being read-only and being hidden from 'ls' >> output. Any user can access the snapshots for any part of the >> filesystem that user ordinarily has access to. No root access is >> required. >> >> Inside the vserver guests it does not work as expected, though. >> Attempting to 'cd .snapshot' never works at all unless BINARY_MOUNT >> is added to ccapabilities. This seems odd to me as there is no >> mounting taking place from what I understand, but the kernel seems to >> think there is. > > there is a mount happening in this case, > because the filer provides the snapshot > as a different (subtree) export > (but it happens inside the kernel) > >> With BINARY_MOUNT added, the root user is then able to access >> .snapshot in all cases. non-root users cannot, though. A non-root user >> CAN access a .snapshot portion of the filesystem after the root user >> has accessed it once previously, though. Here's an example... > > and this works fine on the host system? > (I mean as non-root user on the host?) > >> vserver03:/etc/vservers/patrick# vserver patrick enter >> patrick:/# su - testuser >> [patrick]$ whoami >> testuser >> [patrick]$ cd .snapshot >> -su: cd: .snapshot: Operation not permitted >> # (Note the "Operation not permitted" error) >> >> [patrick]$ logout >> # (back to root now) >> >> patrick:/# cd /home/testuser/.snapshot >> patrick:/# su - testuser >> [patrick]$ cd .snapshot >> # (after accessing it once as root, it's now accessible as the non- >> root user) >> >> [patrick]$ ls >> hourly.0 hourly.1 nightly.0 nightly.1 weekly.0 weekly.1 >> [patrick]$ ls hourly.0 >> ls: hourly.0: Operation not permitted >> # (access one more level down the filesystem is still not permitted) >> >> [patrick]$ logout >> patrick:/# cd /home/testuser/.snapshot/ >> patrick:/home/testuser/.snapshot# ls -l >> total 32 >> drwxr-x--x 7 testuser users 4096 Jul 3 10:53 hourly.0 >> drwxr-x--x 7 testuser users 4096 Jul 3 10:53 hourly.1 >> drwxr-x--x 7 testuser users 4096 Jul 3 10:53 nightly.0 >> drwxr-x--x 7 testuser users 4096 Jul 3 10:53 nightly.1 >> drwxr-x--x 7 testuser users 4096 Jul 3 10:53 weekly.0 >> drwxr-x--x 7 testuser users 4096 Jul 3 10:53 weekly.1 >> >> # (doing an ls -la as root accesses every directory below) >> >> patrick:/home/testuser/.snapshot# su - testuser >> [patrick]$ cd .snapshot/hourly.0 >> [patrick]$ ls >> Maildir logs testdomain.com svn svntest >> [patrick]$ cd ../weekly.1 >> [patrick]$ ls >> Maildir logs testdomain.com svn svntest >> [patrick]$ logout >> >> After the root user ran 'ls -la' inside .snapshot, the non-root user >> could then access all of the hourly.0, weekly.1 etc snapshot >> directories below. > > this is most likely because the entries are > already in the dentry cache on the 'client' > >> Does anyone have any clues about how to fix this? > >> Ideally BINARY_MOUNT would not be needed at all, but > > well, let's postpone this question ... > >> it's ok as long as it works normally for non-root users. >> >> Any ideas are appreciated! > > yeah, please provide the following debug info: > > - complete rpc and nfs(d) debug output for all > cases, i.e. root/user on host/guest > - Linux-VServer debug dmesg output > > we know that the subtree checks (depending on > the nfs version) cause some issues, and I think > we can fix them with sufficient data ... Didn't we come to the conclusion that this problem was due to the extra vx_capable in vfs_kern_mount when this was discussed on IRC, which ought to be just vx_ccaps? > TIA, > Herbert > >> Thanks! >> Dallas -- Daniel Hokka Zakrisson