We see this behavior on occasion as well. Somethings we try: 1) we completely erase the afscache file -- actually stopping the afs client, renaming the existing afscache file, then restarting the client 2) watch the event logs for signs the afs service is stopping and restarting unexpectedly -- we have seen the afs client service restart itself and in process loose tokens -- 3) We did get a patch to fix one problem dealing with cache corruption cause by some old file servers (I think, though secure-endpoints can more fully comment on the fix) 4) Most of the time, we struggle with this kind of issue for days, then the issue vanishes -- The symptoms are as outlined below, windows client, unable to access some locations in afs for which they do have appropriate acls, but which a specific client machine fails to open.
On Fri, Jul 10, 2009 at 7:16 AM, Karen Eldredge < karen.eldre...@infoprint.com> wrote: > > We have a OpenAFS Windows client and the user on that system was not able > to > access one directory even though the ACLs showed he has access permission. > The > user was able to access this directory from another AFS client, so I > believe > that this is an client issue. Since it was just one AFS directory he could > not > access we tried running fs flushv & fs checkv via the Network Identity > manager. > > When trying to access the AFS directory we got the message network > directory > not available (not sure if this is the exact message). Then we ran the > cmdebug > and got the message "failed to get cache entry ... server or network not > responding". We are able to ping the AFS servers. > > When this happens what are the best ways to debug the problem? > > > > _____________________________________________________________________________ > "This message and any attachments are solely for the intended recipient and > may contain confidential or privileged information. If you are not the > intended recipient, any disclosure, copying, use, or distribution of the > information included in this message and any attachments is prohibited. If > you have received this communication in error, please notify us by reply > e-mail and immediately and permanently delete this message and any > attachments. Thank you." > _____________________________________________________________________________ > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- David Bear College of Public Programs at ASU 602-464-0424
