Todd M. Lewis wrote:
> 
> 
> Harald Barth wrote:
>>> [EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
>>> ls: cannot access /afs/grand.central.org/local: No such file or
>>> directory
>>> ls: cannot access /afs/grand.central.org/software: No such file or
>>> directory
>>> total 14K
>>> drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
>>> drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
>>> drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
>>> ?????????? ? ?    ?       ?            ? local
>>> drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
>>> drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
>>> ?????????? ? ?    ?       ?            ? software
>>> drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
>>> drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/
>>
>> That is really strange because I can't see why doc should differ from
>> software. Both are mountpoints with similar ACL and permissions.
> 
> If I had to take a wild guess, I'd say clock drift. Your client's clock
> is far enough off that your token is seen as valid for some servers, but
> invalid for others. I'm guessing that your servers are not totally in
> sync either, maybe just a few seconds or a couple of minutes off, but
> your client's clock is probably right at the edge of too far off.
> 
> You may not have access to the servers themselves, but before you go
> fixing anything else it would be interesting to know what servers "doc"
> and "software" are on vs. the other mountpoints that listed okay.

I'm not experiencing this problem but based upon the previous reports
the problems occur when there are no tokens involved for the cell.

The cell described above is grand.central.org.  The volumes are
root.cell.readonly, root.doc.readonly, root.local.readonly and
root.software.readonly.

All of the volumes except root.doc.readonly are replicated across three
machines: andrew.e.kth.se PENN.CENTRAL.ORG GRAND-OPENING.MIT.EDU.
root.doc.readonly is replicated across two servers: PENN.CENTRAL.ORG
GRAND-OPENING.MIT.EDU

I do not see how clock drift would be involved.

Jeffrey Altman



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to