2

I have a long running bash script that I run on a remote host with screen, so I can log off ssh. When I come back after some time (after logging off), the screen terminal no longer has permissions to access my files and folders.

What's causing this, and is there a way to avoid it?

OS: Scientific Linux CERN SLC release 6.9 (Carbon), using the Andrew File System. I'm using the private directory in AFS, if that makes a difference.

Edit: The screen still has access to my public directory after disconnecting, and other public files. So something about AFS is messing it up.

  • 1
    My first guess (I don't use afs) is that since it's Kerberos-based, your ticket expired. – Jeff Schaller Jul 3 '17 at 16:26
  • If that's the case, is there a way to prevent it from expiring? Or will nohup be a better alternative for running long processes over ssh? I had some problems with nohup too, as described in stackoverflow.com/questions/44802711/…, which I think might be related. – Miatrix Jul 3 '17 at 18:04
  • Diagnostic suggestions: do "whoami" and "id" after relogging in, do "ps" to make sure your screen process is owned by you (same for the 'sleep'/shell process you talk about int he linked question). My wild guess is that you have some sort of weird reaping going once you disconnect. Do you have root on the machine? – barrycarter Jul 3 '17 at 18:24
  • I don't have root permissions. whoami and id properly return my username/gid. ps aux | grep miatrix shows that SCREEN and its bash session are owned by me. – Miatrix Jul 4 '17 at 7:22
0

simply type 'kinit' after reconnecting (and enter your user's password)

0

I had a similar issue, but the AFS disconnect is not immediate and automatic, sometimes the programme will happily run for 6 hours or more before it loses access to AFS. Even if one cleans things with

fs checkservers
fs checkvolumes
fs flush

it still doesn't work or bring AFS access back. Our system manager suggested the following cause and solution:

Cause: "Unfortunately it will not work due to a "new" feature in Linux. I think what is happening is that the systemd deamon that manages system resources/logins aggressively cleans up once it detects a logout (or broken connection) from the remote session, which leads to the destruction of the AFS tokens and hence permission denied error."

Possible workaround: A possible solution is for you to open the screen on one machine then ssh to another machine and start the program running there. For example - login to machine1 then - start a screen session. - From inside the screen session, ssh to machine 2 - start the software to perform analysis. - Detach the session

Hopefully, the above 2 SSH connection can ensure the tokens are kept alive on the 2nd machine."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.