The quick solution is to open a new ticket titled, "I broke my compute symlink," and we'll help you correct it. However, we recommend that you read the following to know what this problem is and how to fix it yourself.

Symbolic Links on FSL

When logged into our systems, a user sees what appears to be a single filesystem in their home directory, with subdirectories such as compute/ and various groups in fsl_groups/. In actuality, multiple filesystems are in use, and several directories are just pointing to different locations on the system. This is why the following output is produced when listing a typical compute "directory" in long form:

ls -ld ~/compute
lrwxrwxrwx 1 <username> <username> 28 Jan 23 09:38 compute -> /lustre/scratch/usr/<username>

The compute directory isn't a directory at all; it's a symbolic link that points to your allocation of compute storage.

How to Fix a Symlink

Some users try to recreate their compute directory with the mkdir command. This is incorrect because all it does is create a new directory in home storage, which is lower performance and limited to 100 GB.

The correct way to recreate a compute link is the following command, using the $USER environment variable to get your username:

ln -s /lustre/scratch/usr/$USER ~/compute

If you already created a compute directory with mkdir and data has been placed in it, then do the following:

• Move any data in compute/ to a temporary location
• Delete the directory with rmdir ~/compute
• Create the proper symbolic link with the command above
• Move any data back into the correctly linked compute/ directory

Job Script Bugs

Occasionally, a user inadvertently deletes their compute/ directory because of a bug in their job script. If you are unaware of how your compute/ directory was deleted or altered, then try reviewing the scripts that you run.