Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm using nohup to launch matlab and run a script which requires to read and write some given files.

nohup matlab -nojvm -nodisplay -r 'MyScript'&

This runs smoothly while I'm logged in but as soon as I log out and log in again I see that my matlab process is no longer running. After checking the nohup.out file I find the following error message:

Unable to write file $HOME/matlab/my_mat_file.mat: permission denied

It seems that as soon as I log out the owner of the matlab process changes and he no longer has access to my files. How can I prevent this error from occurring without changing the file permissions, e.g., by granting write permissions to everyone?

This error message pops up also while using GNU-screen. If I run ls -al $HOME inside my GNU-screen session before log out I'll have

command before log out

I detach form the GNU-screen session, log out, log in, and reattach to the screen session just to find that I lost access to files which I used to have access to inside screen. The output of ls -al $HOME is now

command after log out

Intriguing, isn't it?

share|improve this question
    
Do you have a networked home directory, or encrypted home directory, that vanish when logging out? –  Daniel Beck Jan 2 '13 at 12:44
    
I access an AFS account on a unix cluster using PuTTY. –  vari Jan 2 '13 at 12:47
    
Your problem is probably that the home directory's unmounted when logging out. Verify with a suitable script that e.g. calls ls -la $HOME every second and writes the output to a file in /tmp. –  Daniel Beck Jan 2 '13 at 12:53
    
@Daniel I suppose that if my home directory's where to be unmounted ls wouldn't be able to return its contents, right? Well, I created a GNU-screen session running ls -la $HOME every few seconds while its output was written to a file in /tmp, just like suggested. After detaching from screen and logging out I logged in again and found that there were no difference between the output of ls -al $HOME while logged in or logged out. Note that, even though my question concerns nohup the same problem occurs while using a GNU-screen session. –  vari Jan 3 '13 at 11:34
    
Daniel is talking about autofs - mounting your home directory only when you are logged on. There is no simple workaround for your problem except to ensure you have at least one current interactive process on the box. Create a separate "dummy" session, for example. Or write to files in a known directory like /tmp that does not vanish. –  jim mcnamara Jan 4 '13 at 3:54
add comment

1 Answer 1

up vote 0 down vote accepted

It as to do with authentication.

I'll start with some concepts on tickets and tokens and how Kerberos authentication system and AFS uses them. By the end the answer to my question will be clear, I'm not allowed to write into the file simply because my AFS token was removed at logout. That said, the solution for my problem was to include in the matlab script a few lines which determine if whether the token exists or not creating it in case it doesn't. How has this been done exactly concludes the answer.

Authentication

Providing a distributed file system, accessible form anywhere, implies a robust security system. This is why AFS has a strong authentication system, integrated with the Kerberos authentication system.

Authentication in AFS is solved by means of a token. Tokens grant users access to the data during their life span. In many cases, token handling is seamless, requiring no user intervention. However, the user can, at any given time, list the tokens issued in its name using tokens

username@machine00 ~ $ tokens

Tokens held by the Cache Manager:

User's (AFS ID xxxxx) tokens for afs@your.system.domain [Expires Mar 20 05:10]
   --End of list--

AFS tokens are obtained from a Kerberos identifier ticket. Similarly to tokens Kerberos tickets also identify the user. While using the Kerberos authetication system, the user is issued by the KDC (Key Distribution Center) an initial ticket called ticket-granting ticket. This first ticket uniquely identifies the user and allows him to obtain specific tickets required for further services like the AFS tokens. In fact, you can use directly the Kerberos ticket for the AFS service has the AFS identification token.

In most cases, the Kerberos' ticket-granting ticket is automatically obtained during user login. With the same thing happening for the AFS initial token. Like tokens, Kerberos tickets handling is in most cases invisible for the user but you can list the issued tickets using klist

username@machine00 ~ $ klist
Credentials cache: FILE:/tmp/krb5cc_V16088
        Principal: username@KERBEROS.REALM.DOMAIN

  Issued           Expires          Principal                 
Mar 19 19:10:11  Mar 20 05:10:11  krbtgt/KERBEROS.REALM.DOMAIN@KERBEROS.REALM.DOMAIN
Mar 19 19:10:11  Mar 20 05:10:11  afs/your.system.domain@KERBEROS.REALM.DOMAIN   
username@machine00 ~ $

the credentials cache is the location of the file where tickets are found. The Principal is the user id and basically results from the combination of username and Kerberos' realm domain. Notice that the Kerberos realm is generally given in uppercase and it is case sensitive. Following we have the list of issued tickets, with the corresponding issued and expiration dates. In this case, the first ticket (krtbg) corresponds to the ticket-granting ticket on the realm KERBEROS.REALM.DOMAIN while the second corresponds to the AFS token on the afs cell your.system.domain (which usually has same name as the domain in which it can be found). Other Kerberos tickets may show up in the list in case they have been requested.

Token renewal

When an AFS token expires, the access to the AFS account is no longer possible. The symptoms that such an event as occurred vary from OS to OS, however in Unix/Linux you usually get a permission denied message while trying to access your files:

username@machine00 ~ $ ls
ls: .: Permission denied

When a token expires you need to renew it. An easy way to do it is to logout and login again, since, in most cases, token renewal happens automatically at login. But it turns out that sometimes log out is not an option, especially if you are running something you don't want to exit which is the case.

An alternative solution for ticket renewal is using kinit and aklog, in sequence. The first of these commands (kinit), which requires your password, allows user re-authentication and ticket-granting ticket renewal. Next, aklog command allows you to obtain an AFS token from the Kerberos ticket. Notice that kinit tries to get a ticket for the default principal and realm. In case these are not defined, or if the user is using a different username at time of the ticket request, kinit should be used as kinit @ Caso estes não estejam definidos, ou o utilizador esteja num sistema autenticado com outro username, o comando kinit pode ser usado na forma kinit @, for instance:

username@machine00 ~ $ kinit username@KERBEROS.REALM.DOMAIN
username@KERBEROS.REALM.DOMAIN's Password: 
username@machine00 ~ $

The opposite of aklog is unlog, which deletes the AFS token. Correspondingly, kdestroy removes the tickets' file, deleting all Kerberos tickets.

How this saved the day and helped me love my friends & family

As said in the beginning, knowing about this concepts helped me to better understand what was happening with my matlab session. After logout my AFS token was no longer there and my running processes had no longer permission to write into my afs volume. Since, at the moment, I am only interested in guaranteeing that my matlab script keeps running reading and writing files even after I logout I was careful to include a test on the AFS token previous to any access to the afs volume

ticket_status = unix('klist -s');
if ticket_status ~= 0,
   unix 'kinit username@KERBEROS.REALM.DOMAIN <<< "password"';
   unix  aklog
end

As I said, this goes into the matlab script and I have placed it just before any save or load matlab commands. The code uses matlab command unix to run its arguments on a Unix shell and return the results. The Unix command klist -s runs klist silently but returns its exit status. We test the exit status for credentials and request new ones in case they don't exist or have expired.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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