Troubleshooting AFS problems

Most AFS problems fall into one of the following categories:

• Permission/authentication problems
• Purely network problems
• Caching problems on your local machine
• AFS fileserver issues

Permission & authentication problems

The most common reason for "permission denied" errors is that one's AFS tokens have expired. You can use the tokens command to see the AFS tokens that you hold. If you do not have valid tokens, you can run kinit to authenticate and get new tokens. If you do have valid tokens, you should double-check that you are in the correct ACLs for the directories that you are trying to access. Note that if you are added to an AFS group, you will need to re-authenticate before you can use the permissions for that group.

Network problems

If attempts to access a directory in AFS result in hangs or the directory not being found, you should first check to see if your machine is seeing the network. You can use the ping command to check network connectivity to other hosts (choose a host in the SCS machine room, like cs.cmu.edu). If you know which fileserver the directory is located on, you can ping that fileserver.

Local caching problems

A common AFS problem is either a lack of disk space on the partition where a host's AFS cache is located or corruption of the local AFS cache. If you have trouble accessing files in AFS from a particular host, but can access these files from other hosts, then local AFS cache corruption or disk space issues may be the problem. See the section AFS issues and problems in the Local Unix/Linux Admin's guide for information on how to fix some of these local cache problems. Note that you will need root access on your machine to do this, if you do not have root and/or are not comfortable fixing this type of problem please submit a ticket.

AFS fileserver issues

The following commands can be useful in determining whether something is an AFS fileserver issue:

/usr/local/bin/fs checkservers

The above command checks on the status of AFS fileservers that your local machine's cache manager has recently contacted.

/usr/local/etc/vos examine <volume>

The above command reports on location and status of the given volume. Note that you will have to give the volume name (not the path to the volume).

/usr/local/etc/vos examine user.bovik

You can get a volume name by using the fs lv <path> command. 

fs lv /afs/cs/user/bovik

The volume name for a user will always be of the  user.username.

/usr/local/bin/fs checkvolumes

The command above will check the status of alternate locations of volumes for replicated collections. Doing so may fix some types of AFS access problems.

If you do notice a problem with reaching an AFS volume, please report by submitting a ticket and we will check on the status of the AFS server you are attempting to access.