Hi Russ, I tried to salvage the volumes www and root.cell yesterday evening and the salvager found some wrong vnodes. e.g. 07/14/2009 23:41:18 Vnode 133016: version < inode version; fixed (old status)
Right after that, it worked as expected again but this morning it failed again but with a slight change. In /afs/.<ourcell>, I now have a directory afs and under that the complete AFS tree is accessible (having a directory afs again in the cell root). Looks like I now have a loop in my filesystem like /afs/.<ourcell>/afs/.<ourcell>/... But it doesn't seem to be a mountpoint that I could remove pm3:/afs/.<ourcell> # fs lsmount afs 'afs' is not a mount point. Please note that etch clients are able to see that loop as well >Is the user able to cd out of the chroot, or is this only misleading >output from getcwd? In other words, does cd /afs/.<ourcell> work at this >point? With this loop in place (unintentionally and unwanted) the FTP access now works because the complete directory structure is available in the chroot. I have to fix this as this is a security problem, we intentionally put the users into a chroot so they cannot see the whole tree and how it is exposed to them again :( Any ideas what has happened here and how to fix it? In the state I had yesterday, that loop was not there and so the FTP client just ended up in a directory that looked like an absolute path but internally was relative to the root of the jail and did not exist. I do not know what will come next, but to me it looks like chroot()ing somebody into AFS isn't a good idea on lenny. Cheers, Christian
