Common Errors and Pitfalls

• Upon executing a get command, I receive a message saying to retry once the file is staged and the file does not appear in my local directory. What happened?
• When I retrieve an executable file from MSS and try to execute the file, I get the error message "Permission Denied". Why?
• What does it mean when the command uberftp or mssftp fails with a Invalid CRL: The available CRL has expired error message?

Upon executing a get command, I receive a message saying to retry once the file is staged and the file does not appear in my local directory. What happened?

This behavior occurs because of the way MSS manages performance and space. It manages disk space by automatically migrating files off disk onto tape when space becomes low or if files have not been accessed in a certain length of time. If you need to retrieve a file that has been migrated to tape, the system needs to restore it to MSS disk before it is copied to your local system.

When using "mssftp" on NCSA production systems, the "get" command will yield a message that tells you the file is being retrieved from tape. This is because the "wait" option is turned off by default in the "mssftp" client, so you must issue a second "get" command once the file is on MSS disk. Determinine whether a file is on tape or MSS disk from the 5th column of an "ls" command. "DK" means the file is on MSS disk and "AR" means it is on tape.

Alternatively, toggle wait by typing "wait" *prior* to issuing the first "get" command in the mssftp client. Or use the command line interface to mssftp called "msscmd" instead because it implements the "wait" option by default.

SSH/SFTP clients automatically wait when retrieving archived files from tape. They may display a zero transfer rate during this time, but should automatically begin the download once the archived file is fully transferred to MSS disk.

When I retrieve an executable file from MSS and try to execute the file, I get the error message "Permission Denied". Why?

Files are returned from MSS with only the permissions set by 'umask' (see man umask). To make a file executable, issue the command:

 chmod u+x filename 

(see man chmod) after retrieving your file from MSS before you run it. Alternatively, since 'tar' maintains the permissions of files, you can use 'tar' to save your files in UniTree and avoid using chmod after retrieving executable files (see man tar).

What does it mean when the command uberftp or mssftp fails with a "Invalid CRL: The available CRL has expired" error message?

This error is usually caused by the presences of old(expired) *.r0 files(dot R zero) in "$HOME/.globus/certificates/" directory. The full error message would look something like...


   Failed to init security context
   GSS Major Status: Authentication Failed

   GSS Minor Status Error Chain:
   globus_gsi_gssapi: SSLv3 handshake problems
   globus_gsi_callback_module: Could not verify credential
   globus_gsi_callback_module: Could not verify credential
   globus_gsi_callback_module: Invalid CRL: The available CRL has expired


To fix the issue, move or delete your "certificates" directory in "$HOME/.globus/" and then try your mssftp or uberftp command again. If you are running these commands on NCSA production resources and if the error message remains after you have moved/deleted your "certificates" directory, please notify the Consulting Group.