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 <principal>@<realm>, 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.
ls -la $HOMEevery second and writes the output to a file in/tmp.lswouldn't be able to return its contents, right? Well, I created a GNU-screen session runningls -la $HOMEevery 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 ofls -al $HOMEwhile logged in or logged out. Note that, even though my question concernsnohupthe same problem occurs while using a GNU-screen session.