* Madhusudan Singh [2005-08-12 15:34:14 -0400]: > Tokens held by the Cache Manager: > > User's (AFS ID 2) tokens for [EMAIL PROTECTED] [Expires Aug 13 01:18] > --End of list-- > > omega:~# fs setacl /afs system:anyuser rl > fs: You don't have the required access rights on '/afs' > > Yet again.
Yes, and to me that still smells of a krb.conf problem. Can you show us the ouput of head -1 krb.conf (i.e., the first line of the file)? That should name the realm for your cell, and no other. If that checks out, I'd look at the enctypes for the afs/omega.domain.edu Kerberos principal. Make sure it only has single-DES: no DES3, no AES, etc. At the very least you should check that kinit/aklog got you single-DES AFS service tickets (klist -e (MIT, Sun) or klist -v (Heimdal) should tell). > Out of sheer frustration, > > omega:~# cd /etc/openafs/server > omega:/etc/openafs/server# ln -s /etc/krb.conf . How about a bos restart at this point? > omega:/etc/openafs/server# fs setacl /afs system:anyuser rl > fs: You don't have the required access rights on '/afs' [...] > AFS_DYNROOT=false > > Note the dynroot setting above. Could that be causing this ? No, on the contrary it's more than OK for dynroot to be off at this stage. Were it to be on, then "fs sa /afs" would not act on your cell's root.afs volume at all. (You could still manipulate that ACL by mounting root.afs somewhere else; but I digress.) _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info