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.

Miatrix
  • 121
  • 3
  • 1
    My first guess (I don't use afs) is that since it's Kerberos-based, your ticket expired. – Jeff Schaller Jul 03 '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 https://stackoverflow.com/questions/44802711/stdout-redirection-doesnt-work-when-using-nohup-and-logging-out-of-ssh, which I think might be related. – Miatrix Jul 03 '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? –  Jul 03 '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 04 '17 at 07:22

2 Answers2

0

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

amrual
  • 1
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."

ClimateUnboxed
  • 133
  • 7