* Madhusudan Singh [2008-10-14 11:52:37 -0700]: > >> I am running the latest versions of openafs-modules-source, openafs-client > >> and openafs-krb5 on an up to date installation of Ubuntu Hardy. I used > >> modules-assistant to compile the kernel module against my kernel : > >> $ uname -r > >> 2.6.24-21-generic > >> [...] Stefan Pohl: > > I just completed an OpenAFS-client test setup on Ubuntu Hardy. Same > > versions of the Openafs-stuff, slightly older kernel (2.6.24-19-generic) and > > it works. So it's not broken on Ubuntu Hardy as such. > > Ok. That gives me hope.
I upgraded from -19 to -21 this morning, built and installed openafs-modules-2.6.24-21-generic_1.4.6.dfsg1-2+2.6.24-21.42_i386.deb using m-a as usual, and it still works. > >> :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC > >> bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied > >> > > This look like the user you authenticate as, simply doesn't have the > > required permissions to access the directory. > > Impossible. I can ssh into the server with the same username and password > without any issues. I use rsync to do regular (every 1 hour) backups to this > directory ( a process that is cumbersome, which is why I am looking to set > up my openafs client). All right. Your problem *is* client-side, then. Could you look at the output of "klist -a -n" and verify that your AFS service ticket is for the right address? (Addressless is usually OK.) NAT gateways sometimes interfere. > o/p of fs listacl at the above level (which is one level above my own > directory) : > > $ fs listacl > Access list for . is > Normal rights: > systems:backup rl > system:administrators rlidwka > system:anyuser rl In other words, you don't need a token to get this far: the ACL grants anonymous read access. > I cannot cd into my own directory, so I ssh'ed into the server and issued fs Which authentication method did you use with ssh? Does GSSAPI work? > listacl : > > $ fs listacl > Access list for . is > Normal rights: > systems:backup rl > www-hosts l > system:administrators rlidwka > XYZABC rlidwka Looks good. One question, though: is the server you ran this on a member of www-hosts ? > The owner of all directories under /afs/YYY.EDU/users/X/Y/Z is root.root > (tested both through the local /afs tree and by ssh'ing to the server and > doing a cd ..). I do not recall what this was when things were working fine > (never needed to check), but is this normal (sounds fishy) ? In a different > cell, a long time ago, I seem to vaguely recall that the directory was owned > by the user in question. The UID that owns the volume root has implicit "a" permission on all directories in the volume. That would let you recover from a "fs setacl $HOME XYZABC none" without having to bother the AFS administrators. But since the ACL explicitly grants you full access, you should have full access --- as long as your token is valid. > To test if this was messing up things, I cd'ed to > /afs/YYY.EDU/users/X/Y/Z/XYZABC and issued a command : > > $ cd XYZABC/Private > bash: cd: XYZABC/Private: Permission denied So you were trying to access /afs/YYY.EDU/users/X/Y/Z/XYZABC/XYZABC/Private ? Was this on the server or on your client? If on the client (as your other statements are suggesting), it simply restates that your token is not being accepted. If on the server, I'd want to see the ACL on that subdirectory (and know whether the server is in www-hosts). > This is more nonsense as ~/Private holds my backups :) Maybe the fact that I > do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC is shortcircuiting that command. I don't see how that would work as an explanation. > The owner of all files inside /afs/YYY.EDU/users/X/Y/Z/XYZABC is obviously > XYZABC. Not so obviously since you said that the top-level directory is owned by root, not by XYZABC. You could be locked out of a subdirectory by its ACL. My impression is that the token you got on your client is either invalid or belongs to a different AFS user. The explanations I can think of are (a) that you are behind a NAT and your token is for the wrong address; (b) that you're obtaining the token via Kerberos cross-realm and it's really for user [EMAIL PROTECTED] (in which case you could try fs setacl /afs/YYY.EDU/users/X/Y/Z/XYZABC [EMAIL PROTECTED] all on the server where you do have access, or learn how to authenticate to the correct realm in the first place). Can't the helpdesk at YYY.EDU help you with this? _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info