Skip to content

Your Lab's Storage

This is the single most important page in the user guide. Read it once and save yourself a lot of lost work.

Where your files should live

Location Keep? Use it for
Your lab share (symlinked in ~) Yes — permanent, same from every node All research data, code, notebooks, outputs
/scratch No — local to the node, shared with everyone else on it Temp files, container scratch, fast local I/O
~ (your home directory) No — local to whichever node you land on Nothing important. Dotfiles only.

Your lab share

When your session starts, your lab's NAS shares are mounted on the compute node and symlinks appear in your home directory pointing at each one. Open a terminal and run ls -l ~ — you'll see entries like lab-research, main, nas, etc. depending on how your lab is set up. Use those ~/... paths in your work; they're the simplest way to refer to lab storage.

The exact share names, mount paths, and what each one contains is a per-lab configuration. There's no universal layout — your PI decides what shares exist and who can write where. To see what your lab has:

  • Look in ~ for symlinks at the start of a session.
  • Run mount | grep cifs to see the underlying NAS paths.
  • Ask your lab admin or PI for the intended use of each share.
  • If something doesn't look right, email eit-help@umd.edu and we'll help you map out your lab's storage.

Files you save in a lab share are on the NAS, not on the compute node, so they:

  • Persist forever (until someone deletes them).
  • Are visible from every session, any node, any time.
  • Respect Active Directory permissions — you see what your AD account is allowed to see; if your PI gave you access to a subfolder, you can write to it; if they didn't, you'll get "permission denied."

You don't run cifscreds yourself. When you submit the desktop form, the AD password you enter is consumed once at session start to push your credentials into the kernel keyring (via cifscreds add), and is then thrown away — nothing is written to disk. Walk away from your laptop, lose the AD password, the only impact is that your next session won't see lab storage until you re-enter it. (Direct SSH is the one case where you do run cifscreds add yourself — see direct-ssh.md.)

Examples in the rest of this guide use ~/lab-research as a stand-in for "your lab's share." Substitute whatever symlink name your lab actually has.

Your home directory (~)

Your lab has its own dedicated GPU nodes — typically 1 to 5 of them. Each node has its own local /home, and your $HOME lives on the disk of whichever node your session runs on.

How you end up on a node:

  • From an OOD form — the profile you pick (e.g. Inspire Turing Desktop vs Inspire Searle Desktop) pins your session to one specific node. Same profile = same node = same $HOME. Switch profiles = different node = different (fresh) $HOME.
  • From the Slurm CLI — sbatch / srun without a --constraint pick the least-busy matching node in your lab's partition. If you need to land on a particular node, add a constraint (e.g. --constraint=turing).

So your home is node-local. Two sessions on the same profile see the same ~; sessions on different profiles, or untargeted CLI jobs, may not. Keep dotfiles, conda envs, and anything you can't afford to lose visibility of on your lab share — it's mounted identically on every node.

What you can safely put in ~:

  • Shell dotfiles (.bashrc etc.) — they'll regenerate from /etc/skel each time, or you can version-control them (see below).
  • Tiny, throwaway configs for the current session.

What you must not put in ~:

  • Your code — use ~/lab-research/code/ or similar.
  • Your datasets — on lab storage.
  • Your conda envs — see python-and-conda.md for the right place.
  • Anything you don't want to redo tomorrow.

Persistent dotfiles

If you like a specific .bashrc, .vimrc, .tmux.conf, etc., the most reliable pattern is to keep them in a git repository on lab storage and re-link them each session:

# Once, from any session:
cd ~/lab-research
git clone https://github.com/<you>/dotfiles

# At the start of each session:
cd ~
ln -sf ~/lab-research/dotfiles/.bashrc .bashrc
ln -sf ~/lab-research/dotfiles/.vimrc  .vimrc
# etc

Automate this: put those ln -sf commands in a file on lab storage (say ~/lab-research/bin/setup-home.sh) and run it from a terminal at session start.

Tools like stow are worth a look if you have a large dotfiles collection.

/scratch — fast temp space

/scratch is local SSD on whichever node you land on, shared by everyone running on that node (like /tmp, with a sticky bit so you can only delete your own files). Use it when:

  • You're pulling a large container image or extracting a big archive and want fast I/O.
  • A tool (fmriprep, etc.) needs temp space and defaults to /tmp which is small.
  • You're iterating on intermediate files that don't need to survive.

Nothing auto-cleans /scratch — files stick around until someone (you, ideally) deletes them. Two etiquette points:

  • Make a per-job or per-user subdirectory (mkdir -p /scratch/$USER/$SLURM_JOB_ID) so it's obvious what's yours.
  • Clean up at the end of your job before the share fills up. A trailing rm -rf /scratch/$USER/$SLURM_JOB_ID at the end of your sbatch script is the easiest pattern.

Copy anything you want to keep to your lab share before deleting.

Example — tell fmriprep to use /scratch for its working dir:

mkdir -p /scratch/$USER/fmriprep-work
fmriprep ~/lab-research/bids ~/lab-research/derivatives participant \
    --work-dir /scratch/$USER/fmriprep-work
rm -rf /scratch/$USER/fmriprep-work

File ownership and permissions

Your Linux user has a fixed UID across all nodes — files you write on lab storage appear owned by "you" everywhere.

For AD-backed ACLs on the NAS, the Synology enforces per-user access. If you create a folder, the AD ACL is set to what your AD session has rights to do. If a file won't open for a labmate, check the AD permissions on the Synology side with your lab admin.

Transferring files off the system

A few options:

  • Files app in OOD. Navigate to any path and use "Download." Good for a handful of files.
  • scp or rsync from your laptop. See direct-ssh.md for enabling SSH. Best for big transfers.
  • Your lab's existing workflow. Many PIs already have a Dropbox-style or web-accessible route into the NAS. Ask.

When your lab share looks empty

The most common cause is a wrong AD password at session start — the mount is up but your kernel keyring doesn't have valid credentials. End the session, relaunch, re-enter the AD password carefully.

Other causes and how to fix them live in faq.md.