Our $HOME file system is an openAFS system. I log on to my desktop machine from my laptop at home and want to run a long job. Thus to protect it from a broken session, I open up

screen -S session_name

and run the script from there, and then disconnect the screen session. My problem is that after a relatively short time of a few hours, the session loses contact to the AFS file system, so I can't use any files there in the script stored on my $HOME. If I reconnect later to the session I can't list any files there or change directory to my home, I simply get a permission denied error.

I tried the following commands to try and reconnect, which usually work if I have left my desktop logged in too long:

fs checkservers
fs checkvolumes
fs flush

but that doesn't help the screen session to reconnect. Does anyone know how I can keep access to AFS in a disconnected screen session, or place a command in my bash/python scripts to keep it alive?

2 Answers 2


I suggest running krenew, which has the option to run a command with the -t flag, which by default is aklog. It’s usually packaged as part of the kstart package.

Run the krenew inside the screen session. Make sure you get renewable Kerberos tickets, and your institutions KDC might have limits on how long your ticket can be renewed. As long as the Kerberos ticket is valid, krenew will run aklog and get updated tokens.

If you want to keep the ticket for a long while, make sure that the credential cache is the same every time you log in (for example, use the KEYRING), that way every time you ssh in, the krenew process will have access to the refreshed tgt. You set the default ccache name in /etc/krb5.conf.

I basically do this with tmux, and I also use the kAFS client as well as OpenAFS for home directories.

  • Thank you so much for the suggestion, I'm getting an error: error reading ticket cache: No credentials cache found (filename: /tmp/krb5cc_8619_llISU1), do I need to use kinit first when I first open the screen session? Jun 9, 2020 at 9:48
  • Yes, krenew only works with an existing Kerberos ticket.
    – jsbillings
    Jun 9, 2020 at 12:45

So this is a solution that was suggested to me to try today.

First Login to the computer in question via ssh

Then run the following command to create a new kerberos/AFS session.


Run the following to authenticate again with AFS


Use the following command to verify that you have a token


Run screen with the -l option to force a login shell

screen -l -S session_name

Start your application and disconnect... So far it seems to work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .