# How to Set Up Your Home Directory for Bioinformatics

By the end of this guide you will have a home directory that can hold raw sequencing data, reference genomes, installed tools, analysis scripts, and results without turning into an unsearchable pile of files. You will have a configured shell that remembers your history, finds your tools, and behaves the same way on every server you log into. You will know how to check your disk usage, back up the files that matter, and fix the five or six errors that account for most beginner frustration in Linux for bioinformatics.

You need one thing before you start: a terminal on a Unix-like system. That can be a native Linux machine, a macOS laptop, an institutional high-performance computing (HPC) cluster where you have an account, or Windows with the Windows Subsystem for Linux (WSL2) installed. Every command in this guide runs in the Bash shell, which is the default on most Linux distributions and clusters. No software needs to be installed before Step 1, and every command shown is a standard tool that ships with the operating system or is documented by its own project.

## Why a Deliberate Home Directory Structure Matters

A bioinformatics home directory setup is not decoration. It is the difference between an analysis you can rerun in six months and an analysis you have to rebuild from memory. Three forces shape how bioinformaticians organize their home directories.

First, reproducibility. Analyses in this field chain many tools together. A workflow that reads raw FASTQ files, aligns them to a reference genome, and writes count tables will touch dozens of files. If raw data, references, scripts, and outputs live in predictable places, a collaborator or reviewer can rerun the work with confidence. If they live in folders named `stuff`, `stuff2`, and `Desktop`, they cannot.

Second, the realities of shared systems. Most HPC clusters give each user a home directory with a strict quota, often measured in tens of gigabytes, and treat it as the place for code, configuration, and small permanent files. The same clusters provide a separate high-capacity scratch or project filesystem for large datasets. Cluster documentation is consistent on this point: home directories are frequently backed up but small, and filling them causes problems for you and sometimes for everyone on the node. A good bioinformatics home directory format plans for both locations from day one.

Third, tool conventions. Software makes assumptions about where things live. The NCBI BLAST+ command line documentation, for example, expects you to either point BLAST at a database location or manage a database directory yourself. Package managers such as conda install into a prefix you choose. The freedesktop.org XDG Base Directory Specification, which many modern tools follow, places user configuration in `~/.config`, cached data in `~/.cache`, and persistent application data in `~/.local/share`. When your own layout cooperates with these conventions, configuration problems mostly disappear.

## Core Concepts You Need Before Typing Commands

### The home directory and $HOME

Your home directory is the directory you land in when you log in. On most Linux systems it is `/home/yourusername`, and on macOS it is `/Users/yourusername`. The shell stores this path in a variable called `HOME`, and the tilde character `~` is a shorthand for it. The GNU Bash Reference Manual documents tilde expansion and shell variables such as `HOME` and `PATH` in detail. When you see `~/projects` in any documentation, it means "the `projects` folder inside my home directory."

### Hidden files and dotfiles

Files whose names begin with a dot, such as `.bashrc`, are hidden by default. The `ls` command needs the `-a` flag to show them. These dotfiles hold your personal configuration, and almost every problem described later in this guide traces back to one of them. You will edit exactly one of them in this walkthrough: `.bashrc`.

### PATH and how the shell finds programs

When you type `blastn` and press Enter, the shell does not search the whole filesystem. It searches a list of directories stored in the `PATH` variable, in order, and runs the first match it finds. If the directory containing a program is not in `PATH`, you get a `command not found` error no matter how correctly the program was installed. Managing `PATH` is therefore the single most important shell configuration task in a bioinformatics home directory setup.

### Permissions in brief

Unix systems attach three permission sets to every file and directory: read (`r`), write (`w`), and execute (`x`), assigned separately to the owner, the group, and everyone else. The GNU Coreutils manual, which documents `ls`, `chmod`, `mkdir`, `du`, and most of the other commands in this guide, describes this numeric and symbolic permission model. For this walkthrough you only need two operations: `chmod +x` to make a script executable, and the knowledge that a directory must be executable (traversable) for you to enter it.

## A Bioinformatics Home Directory Template

This is the layout format I recommend, and it scales from a laptop to a cluster login node. Each directory has one job.

| Directory | Purpose | Typical contents |
|--|--|--|
| `~/projects/<name>/` | One folder per analysis, self-contained | Everything belonging to that analysis |
| `~/projects/<name>/data/raw/` | Original, never-modified input data | FASTQ, VCF, images as received |
| `~/projects/<name>/data/processed/` | Files generated from raw data | Trimmed reads, BAM files, count matrices |
| `~/projects/<name>/references/` | Reference files for this project only | Genome FASTA, annotation GTF/GFF |
| `~/projects/<name>/scripts/` | Code that runs the analysis | Shell scripts, Python, R |
| `~/projects/<name>/results/` | Final outputs worth keeping | Tables, figures, reports |
| `~/projects/<name>/logs/` | Tool output and error logs | `.log` and `.err` files with dates in names |
| `~/projects/<name>/metadata/` | Sample sheets and design files | CSV sample tables, filenames, conditions |
| `~/db/` | Shared reference assets used by many projects | BLAST databases, genome indices |
| `~/bin/` | Your own small scripts and executables | Personal wrappers on `PATH` |
| `~/software/` | Manually installed programs when conda is not an option | Cloned repositories, compiled binaries |
| `~/scratch/` | Short-lived intermediates, safe to delete | Temporary files during a run |
| `~/archive/` | Compressed old projects moved off the active area | `.tar.gz` bundles |

Two design decisions in this template deserve explanation.

Raw data is treated as read-only. After data arrives from a sequencer or a collaborator, it is copied into `data/raw/` and never edited. Every processing step writes to `data/processed/`. If a step goes wrong, you delete the processed output and rerun from raw. You never face the question "was this FASTQ file the original or a modified copy?"

The `~/db/` directory holds reference assets shared across projects. Building a BLAST database or a genome index takes real time, and doing it once in a central location instead of once per project saves hours. The NCBI BLAST+ documentation supports keeping databases in a stable location and pointing tools at it explicitly.

## Step-by-Step Walkthrough

![Flow from orienting yourself through shell config, conda and the final checklist.](/article-images/illustrations/bioinformatics-home-directory-setup-setup-order.webp)

The next twelve steps are ordered. Each one builds on the last, and each shows expected output so you can confirm you are on track.

### Step 1. Orient yourself

Log in and confirm where you are and who you are. Four commands answer this.

```
whoami
hostname
pwd
echo $HOME
```

Expected output on a typical cluster:

```
zkhalid
hpc-login02
/home/zkhalid
/home/zkhalid
```

`whoami` prints your username, `hostname` prints the machine name, and `pwd` (print working directory) prints your current location. `echo $HOME` prints the value of the `HOME` variable. If `pwd` and `echo $HOME` disagree, you are in a subdirectory, which is fine, but know where you are before creating anything.

Check which shell you are running, because the configuration file you edit depends on it.

```
echo $SHELL
```

Expected output:

```
/bin/bash
```

If this prints `/bin/zsh` or `/bin/tcsh`, the `.bashrc` guidance below needs small adjustments, since zsh reads `.zshrc` and tcsh reads `.tcshrc`. The Bash Reference Manual explains the distinction between login shells, which read `.bash_profile` or `.profile`, and interactive non-login shells, which read `.bashrc`. On most cluster systems, terminal sessions are interactive non-login shells, so `.bashrc` is the file that matters.

### Step 2. Inspect what is already there

Look at your home directory, including hidden files, with human-readable sizes.

```
ls -lah
```

Expected output (abbreviated):

```
total 64K
drwxr-xr-x 12 zkhalid zkhalid 4.0K Nov 11 09:14 .
drwxr-xr-x  3 root    root    4.0K Sep 02 08:00 ..
-rw-r--r--  1 zkhalid zkhalid  220 Sep 02 08:00 .bashrc
drwxr-xr-x  2 zkhalid zkhalid 4.0K Sep 02 08:00 .cache
drwxr-xr-x  2 zkhalid zkhalid 4.0K Sep 02 08:00 .config
drwxr-xr-x  2 zkhalid zkhalid 4.0K Sep 02 08:00 .ssh
-rw-r--r--  1 zkhalid zkhalid  807 Sep 02 08:00 .profile
```

The parameters here matter and you will use them constantly. `-l` produces the long listing with permissions, owner, size, and modification date. `-a` includes hidden files. `-h` prints sizes in human-readable units such as `4.0K` instead of raw byte counts. The `-h` flag is available on most Coreutils commands for the same reason.

The first line, `total 64K`, is the sum of block usage in the directory. The single-dot entry `.` is the current directory and the double-dot entry `..` is the parent. The ten-character string at the start of each line, such as `drwxr-xr-x`, encodes the file type and permissions. A leading `d` means directory, and the nine following characters are the read, write, and execute bits for owner, group, and others in that order.

Now measure how much space you already consume, because everything you add later fits inside a quota.

```
du -s -h ~
```

Expected output:

```
2.3G    /home/zkhalid
```

`du` (disk usage) sums file sizes, `-s` prints a single summary total rather than every subdirectory, and `-h` renders it in readable units.

### Step 3. Build the directory skeleton

Create the entire template in one command using two features: `mkdir -p`, which creates parent directories as needed and stays silent if a directory already exists, and brace expansion, a Bash feature that expands a comma-separated list inside braces into multiple arguments.

```
mkdir -p ~/projects ~/db/blast ~/bin ~/software ~/scratch ~/archive
```

Brace expansion also lets you build a complete project scaffold. Create a first project to practice on:

```
mkdir -p ~/projects/rnaseq_trial/{data/{raw,processed},references,scripts,results,logs,metadata,doc}
ls ~/projects/rnaseq_trial
```

Expected output:

```
data  doc  logs  metadata  references  results  scripts
```

Note that `ls` without arguments lists the current directory contents only one level deep. To confirm the full structure you created, use `find`, which walks directories recursively, with `-type d` to list only directories and `-maxdepth 2` to limit how deep it goes.

```
find ~/projects/rnaseq_trial -maxdepth 2 -type d
```

Expected output:

```
/home/zkhalid/projects/rnaseq_trial
/home/zkhalid/projects/rnaseq_trial/data
/home/zkhalid/projects/rnaseq_trial/data/raw
/home/zkhalid/projects/rnaseq_trial/data/processed
/home/zkhalid/projects/rnaseq_trial/references
/home/zkhalid/projects/rnaseq_trial/scripts
/home/zkhalid/projects/rnaseq_trial/results
/home/zkhalid/projects/rnaseq_trial/logs
/home/zkhalid/projects/rnaseq_trial/metadata
/home/zkhalid/projects/rnaseq_trial/doc
```

`-p` deserves one more sentence. Without it, `mkdir` fails if a parent directory does not exist, so `mkdir data/raw` fails when `data` is missing. With it, the command builds the full chain. This is why nearly every bioinformatics script starts with `mkdir -p` on its output directories.

### Step 4. Document each project with a README

Inside `doc/`, create a plain text README that records what the project is, where the data came from, and how it was run. Use `nano`, which is present on nearly every system, or any editor you prefer.

```
nano ~/projects/rnaseq_trial/doc/README.md
```

Write a short header, for example:

```
# rnaseq_trial

Goal: differential expression of treated versus control samples.

Data source: 6 FASTQ files from the core facility, received 2026-11-10.
Reference: GRCh38, downloaded to ~/db/genomes/grch38.

Run notes and dates are appended below as work proceeds.
```

Save with Ctrl+O and Enter, exit with Ctrl+X. Six months from now, this file is worth more than any other file in the project.

### Step 5. Configure your shell in .bashrc

Open your `.bashrc` for editing:

```
nano ~/.bashrc
```

Append the following block at the end of the file. Each line is explained below the code.

```
# ---- Bioinformatics personal settings ----

# Keep a long, duplicate-free command history across sessions
export HISTSIZE=50000
export HISTFILESIZE=100000
export HISTCONTROL=ignoredups
shopt -s histappend

# Prompt showing user, host, and full working directory
export PS1='\u@\h:\w\$ '

# Personal scripts directory first in the search path
export PATH="$HOME/bin:$PATH"

# Frequently used aliases
alias ll='ls -alh'
alias dush='du -s -h'
alias p='cd ~/projects'
```

The history settings control how many commands the shell remembers. `HISTSIZE` is the number of commands kept in memory, `HISTFILESIZE` is the number written to the `.bash_history` file, and `HISTCONTROL=ignoredups` stops consecutive duplicate commands from being recorded. `shopt -s histappend` makes new history append to the file instead of overwriting it, which matters when you hold several terminal sessions open at once. These are all documented shell variables and options in the Bash Reference Manual. Long command history is quietly one of the most valuable tools in bioinformatics, because it is a record of exactly what you ran and in what order.

`PS1` sets the prompt. `\u` inserts your username, `\h` the hostname, `\w` the full current path, and `\$` the prompt character. Seeing the full path prevents the classic mistake of running a script while thinking you are somewhere else.

The `PATH` line prepends `~/bin` to your search path. Because the shell searches `PATH` directories in order, putting `~/bin` first means your personal version of a tool wins over a system copy if names collide. The `$PATH` at the end preserves every directory already configured, including the conda block added later.

The aliases are shortcuts. `ll` gives the detailed listing from Step 2, `dush` gives the one-line disk total, and `p` jumps to your projects folder. Aliases cannot override a command given with its full path, so they add convenience without hiding anything.

Save the file, then apply it to your current session. Editing `.bashrc` changes only the file, not any shell already running.

```
source ~/.bashrc
```

Your prompt changes immediately to the new `user@host:path$` format. To verify the path change:

```
echo $PATH
```

Expected output (the leading entry is new):

```
/home/zkhalid/bin:/usr/local/bin:/usr/bin:/bin:...
```

### Step 6. Create and use your personal bin directory

`~/bin` already exists from Step 3. Put small helper scripts there and make them executable. Here is a genuinely useful one, a script that prints disk usage broken down by first-level subdirectory of a given path.

```
nano ~/bin/dirdisk
```

Contents:

```
#!/bin/bash
# Report disk usage one level deep under a directory.
# Usage: dirdisk [directory]
target="${1:-.}"
du -h -d 1 "$target" | sort -h
```

Save, then make it executable and run it.

```
chmod +x ~/bin/dirdisk
dirdisk ~
```

Expected output:

```
4.0K    /home/zkhalid/db
4.0K    /home/zkhalid/archive
8.0K    /home/zkhalid/bin
412K    /home/zkhalid/software
2.3G    /home/zkhalid/projects
2.3G    /home/zkhalid
```

Three parameters in the script are worth understanding. The shebang line `#!/bin/bash` tells the kernel to run the file with Bash. `"${1:-.}"` means "the first argument, or the current directory if no argument was given," which is Bash parameter expansion. `du -d 1` limits the report to one directory level, and `sort -h` sorts human-readable sizes numerically so `2.3G` sorts after `412K`.

Because `~/bin` is now first in `PATH`, typing `dirdisk` from any directory works.

### Step 7. Install a package manager and keep environments separate

Manual software installation scatters binaries and libraries across your home directory and creates version conflicts. Conda solves both problems by installing software into isolated, named environments under a single prefix you control. This is the standard approach for Linux for bioinformatics on machines where you lack administrator rights.

Download and install Miniconda, the minimal conda installer, into your home directory.

```
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/software/miniconda3
rm Miniconda3-latest-Linux-x86_64.sh
```

The two installer parameters matter. `-b` runs the installer in batch mode, meaning it accepts defaults and does not ask interactive license questions, which is essential on a cluster where the installer may be run inside a script. `-p` sets the installation prefix explicitly, here placing conda under `~/software/miniconda3` so it lives inside your organized software area rather than scattering a new folder at the top level of your home directory. The conda documentation describes these installer options and the prefix model.

Register conda with your shell. This appends a managed initialization block to your `.bashrc`:

```
$HOME/software/miniconda3/bin/conda init bash
source ~/.bashrc
```

After this, your prompt gains an environment prefix such as `(base)`, and `conda` works as a plain command. Create a named environment for a real toolchain:

```
conda create -n rnaseq -y
conda activate rnaseq
```

Expected output after activation is a changed prompt:

```
(rnaseq) zkhalid@hpc-login02:~$
```

`-n` names the environment and `-y` confirms the creation without an interactive prompt. Inside an activated environment, anything you install with `conda install -y fastqc multiqc` is available only while that environment is active, which prevents the version conflicts that make Bioinformatics environments fragile. Leave an environment with `conda deactivate`. List environments with `conda env list`.

### Step 8. Place reference data and databases in their home

Download a reference genome into the shared `~/db` area and build a BLAST database against it, following the layout recommended by the BLAST+ command line documentation.

```
mkdir -p ~/db/genomes
cp ecoli_k12_mg1655_genome.fna ~/db/genomes/
makeblastdb -in ~/db/genomes/ecoli_k12_mg1655_genome.fna -dbtype nucl -out ~/db/blast/ecoli_k12 -title "E. coli K-12 MG1655"
```

Expected output (typical):

```
Building a new DB, current time: 11/11/2026 10:22:41
New DB name:   /home/zkhalid/db/blast/ecoli_k12
New DB title:  E. coli K-12 MG1655
Sequence type: Nucleotide
Keep MBs: 1
Added 1 sequences in 0.039 seconds.
```

Each parameter does one job. `-in` names the input FASTA. `-dbtype` declares the molecule type, `nucl` for nucleotide or `prot` for protein, and this flag is mandatory. `-out` sets the database prefix, and everything BLAST generates will share that prefix. `-title` sets a human-readable label stored inside the database. The BLAST+ documentation covers these options and the companion `blastdbcmd` tool for inspecting finished databases.

Verify the database with a real search:

```
blastn -query test_query.fa -db ~/db/blast/ecoli_k12 -outfmt 6 -out test_hits.tsv
head test_hits.tsv
```

Expected output is tab-separated hit lines, for example:

```
contig_1  NC_000913.3  92.135  415  31  2  12  424  3482743  3482331  1.2e-158  553
```

The `-outfmt 6` option requests tabular output, which is the format most downstream scripts expect.

### Step 9. Link large shared data instead of copying it

Institutional servers often hold large datasets on a shared read-only filesystem. Never copy multi-hundred-gigabyte datasets into your home directory. Link them.

```
ln -s /shared/refdata/grch38 ~/db/genomes/grch38_link
readlink -f ~/db/genomes/grch38_link
```

Expected output of the second command:

```
/shared/refdata/grch38
```

`ln -s target linkname` creates a symbolic link, a pointer that behaves like the target for reads but occupies almost no space. The argument order trips people up, so remember that the target comes first, the same order you would say "link to that." `readlink -f` resolves a link all the way to its final absolute path, which is how you confirm a link points where you think it does.

### Step 10. Stay under quota

Quota problems on shared systems cause silent data loss and angry systems administrators. Check usage regularly, per directory rather than only in total.

```
dirdisk ~
quota -s
```

Expected output of `quota -s` on a system with quotas enabled:

```
Disk quotas for user zkhalid (uid 10241):
     Filesystem   blocks   quota   limit   grace   files   quota   limit   grace
      /home       2311M    20G     25G             18412   100k    110k
```

The `quota -s` command prints your assigned block quota (soft limit, where a grace period begins) and hard limit (absolute ceiling), plus file-count quotas. Not every system runs quota software, so if this prints nothing or reports an error, rely on `dirdisk` and `df -h $HOME` instead, where `df` reports overall filesystem capacity.

### Step 11. Back up the irreplaceable and plan to rebuild the rest

A useful principle separates your files into two classes. Code, configuration, metadata, and small results are irreplaceable and should be backed up. Raw data, databases, and conda environments are large and can be re-downloaded or re-created, so they need a documented rebuild procedure more than a backup.

Back up your projects folder with `rsync`, the standard tool for efficient synchronized copies. Its manual documents the option set in detail.

```
rsync -avh ~/projects/ /mnt/external_backup/projects/
```

The options are `-a` for archive mode, which preserves permissions, timestamps, and directory structure and implies recursion, `-v` for verbose listing of transferred files, and `-h` for human-readable sizes. Subsequent runs copy only what changed.

One trailing-slash detail causes real data loss and must be stated plainly. `rsync -avh ~/projects/ dest/` copies the contents of `projects` into `dest`, while `rsync -avh ~/projects dest/` copies the `projects` folder itself into `dest`, producing `dest/projects`. Decide which you mean every single time.

### Step 12. Version control your code and configuration

Initialize a Git repository in your project so every script change is recorded. Git's own documentation covers the three commands used here.

```
cd ~/projects/rnaseq_trial
git init
git add scripts/ doc/README.md
git commit -m "Initial analysis scripts and README"
```

Expected output:

```
[main (root-commit) a1b2c3d] Initial analysis scripts and README
 4 files changed, 87 insertions(+)
 create mode 100644 doc/README.md
 create mode 100755 scripts/run_alignment.sh
```

Do this once per project. Over time the commit log becomes a [lab notebook](/knowledge/molecular-biology/lab-notebook) of what changed and when.

### Step 13. Verify the whole setup

Run this checklist. Each command should succeed silently or print the value shown.

```
test -d ~/projects && echo "projects: OK"
test -d ~/db && echo "db: OK"
test -x ~/bin/dirdisk && echo "dirdisk executable: OK"
grep -q '$HOME/bin' ~/.bashrc && echo "PATH edit present: OK"
echo $PATH | grep -q "$HOME/bin" && echo "PATH active: OK"
```

Expected output:

```
projects: OK
db: OK
dirdisk executable: OK
PATH edit present: OK
PATH active: OK
```

`test -d` returns success if a directory exists, `test -x` if a file is executable, and the `&&` operator runs the second command only when the first succeeds. The difference between the last two checks matters: `grep` on `.bashrc` confirms the file was edited, while `echo $PATH` confirms the running shell picked it up. A file edit without an active effect means you forgot `source ~/.bashrc` in the current session.

## A Worked Bioinformatics Home Directory Setup Example

The following transcript shows the entire setup on a fresh account, condensed to the commands that change state, with representative output. Use it as a ground-truth reference for the bioinformatics home directory setup example you compare your own session against.

```
zkhalid@hpc-login02:~$ whoami
zkhalid
zkhalid@hpc-login02:~$ echo $SHELL
/bin/bash
zkhalid@hpc-login02:~$ mkdir -p ~/projects ~/db/blast ~/bin ~/software ~/scratch ~/archive
zkhalid@hpc-login02:~$ mkdir -p ~/projects/rnaseq_trial/{data/{raw,processed},references,scripts,results,logs,metadata,doc}
zkhalid@hpc-login02:~$ ls ~/projects/rnaseq_trial
data  doc  logs  metadata  references  results  scripts
zkhalid@hpc-login02:~$ echo $PATH | grep -c "$HOME/bin"
1
zkhalid@hpc-login02:~$ ~/software/miniconda3/bin/conda init bash
no change     /home/zkhalid/software/miniconda3/condabin/conda
modified      /home/zkhalid/.bashrc
zkhalid@hpc-login02:~$ source ~/.bashrc
(base) zkhalid@hpc-login02:~$ conda create -n rnaseq -y
...
# To activate this environment, use
#     $ conda activate rnaseq
(base) zkhalid@hpc-login02:~$ conda activate rnaseq
(rnaseq) zkhalid@hpc-login02:~$ conda install -y fastqc multiqc
...
(rnaseq) zkhalid@hpc-login02:~$ fastqc --version
FastQC v0.12.1
```

Two details in this transcript reward attention. The `conda init` output line `modified /home/zkhalid/.bashrc` confirms where the configuration landed. The prompt prefix `(rnaseq)` is your constant visual proof of which environment is active, which prevents the most common container-mixup error in day-to-day analysis.

## Command Reference Table

| Command | What it does | Key options and meaning |
|--|--|--|
| `pwd` | Print current directory | No options needed |
| `ls -lah` | List files with sizes, including hidden files | `-a` hidden files, `-l` details, `-h` human sizes |
| `mkdir -p a/b/c` | Create nested directories, no error if they exist | `-p` build parents as needed |
| `du -s -h ~` | Total size of a directory tree | `-s` summary, `-h` human sizes |
| `du -h -d 1 dir` | Size one directory level deep | `-d N` depth limit |
| `df -h $HOME` | Filesystem capacity and usage | `-h` human sizes |
| `chmod +x file` | Make a file executable | Symbolic mode changes user bits |
| `ln -s target link` | Create a symbolic link | Target first, link name second |
| `readlink -f link` | Resolve a link to its absolute target | `-f` follow all levels |
| `rsync -avh src/ dest/` | Synchronized, incremental backup copy | `-a` archive, `-v` verbose, `-h` human |
| `export PATH=...` | Prepend a directory to the command search path | Searched left to right |
| `source ~/.bashrc` | Reload shell configuration now | Equivalent to `. ~/.bashrc` |
| `conda create -n name -y` | Create an isolated software environment | `-n` name, `-y` auto-confirm |
| `makeblastdb -in f -dbtype t -out p` | Build a BLAST database | `-dbtype` is `nucl` or `prot` |
| `git init`, `git add`, `git commit -m` | Track file history in a repository | Commit messages document changes |

## Common Errors and Exact Fixes

These are the errors you will actually hit during a home directory setup, with the exact messages and the fix for each.

### `bash: fastqc: command not found`

The shell could not find the program in any `PATH` directory. Fix in order: confirm the environment is active with `conda env list`, activate it with `conda activate rnaseq`, and if the tool is not installed in that environment, install it with `conda install -y fastqc`. To see every directory the shell searched, run `echo $PATH`.

### `cat: sequence.fasta: Permission denied`

You lack read permission on the file, or the directory above it is not traversable by you. Check with `ls -l sequence.fasta` and `ls -ld ..`. If the file is yours, `chmod u+r sequence.fasta` grants read access to the owner. If the file belongs to another user or a shared group, ask the owner to grant access rather than changing permissions on data you do not own.

### `write error: No space left on device` and `Disk quota exceeded`

The first message means the filesystem is physically full. The second means your personal quota, not the disk, is the constraint, which is the common case on HPC systems. Diagnose with `dirdisk ~` and remove or compress the largest avoidable directories, usually `~/scratch` contents and old intermediate files. Then move large collections to the scratch or project filesystem your cluster provides and link them back with `ln -s` as shown in Step 9. Files in `~/.cache` can usually be deleted safely, since the XDG specification defines that directory as regenerable cached data.

### `ln: failed to create symbolic link 'results/alignments': File exists`

A file or link already occupies the name. Inspect it with `ls -l results/alignments`. If it is a stale link you want replaced, remove it with `rm results/alignments` and rerun `ln -s`. Links to directories can be followed into accidentally, so check with `readlink -f` before deleting anything.

### `cp: omitting directory 'data'`

`cp` without `-r` refuses to copy directories. Use `cp -r data/ destination/`, where `-r` means recursive.

### `conda: command not found` after installation

The shell started before conda was initialized, or you skipped the `source ~/.bashrc`. Run `source ~/.bashrc`. If that fails in a fresh login, confirm the initialization block exists with `grep conda ~/.bashrc` and rerun `conda init bash` using the full path to the conda binary as shown in Step 7.

### `bash: /home/zkhalid/.bashrc: Permission denied`

Your `.bashrc` lost its read or execute permission, which occasionally happens after copying files from Windows or a USB drive. Restore it with `chmod 644 ~/.bashrc` and reload.

### `bash: /bin/ls: Argument list too long`

Glob patterns such as `rm *.fastq` expand to a command line too long for the system limit, common with directories holding hundreds of thousands of files. Use `find` instead, which walks the filesystem without expanding the command line: `find . -name '*.fastq' -delete`. Test the match first with `find . -name '*.fastq' | head` before adding `-delete`.

## Common Mistakes and Limitations

![Decision path asking whether data is large, shared or irreplaceable to pick home, scratch, shared storage or backup.](/article-images/illustrations/bioinformatics-home-directory-setup-where-files-live.webp)

Every mistake below comes from real setups, including my own early ones.

Storing large raw data in the home directory on shared systems. Home quotas exist precisely because home directories are small and frequently backed up. Multi-gigabyte FASTQ collections belong on the scratch or project filesystem, referenced by links. This is the single most common beginner error on clusters.

Editing the wrong shell configuration file. Changes to `.bash_profile` that never appear in cluster terminal sessions, or changes to `.bashrc` that never appear in login shells, confuse people for weeks. Know which file your shell reads in which context, and when in doubt put personal settings in `.bashrc`.

Hardcoding absolute paths in scripts. A script containing `/home/zkhalid/...` breaks on every other machine and account. Refer to paths relative to the script or project, or define them once as variables at the top of the script.

Mixing raw and processed data. If a single directory holds both original and derived files, no one can later tell which is which. The template separates `data/raw/` from `data/processed/` for exactly this reason.

Granting broad permissions to fix access problems. `chmod -R 777` makes everything writable by everyone and is a security problem as well as a habit-forming shortcut. Grant the specific permission needed, to the specific user or group, with `chmod`.

Assuming the home directory is backed up on every system. Some clusters back up home directories, some do not, and some purge inactive scratch data on a fixed schedule. Check your institution's documentation and keep the Step 11 principle regardless: small irreplaceable files get backed up, large re-obtainable files get a documented rebuild path.

Editing the managed conda block in `.bashrc` by hand. `conda init` writes and maintains a marked block, and manual edits inside it are overwritten by the next `conda init`. Put personal settings after that block, clearly separated by a comment.

One limitation applies to everything above. Computing environments differ. A laptop, a university cluster, and a cloud instance impose different quotas, module systems, and policies, and no single template fits all of them perfectly. The structure here is deliberately portable, but always check your own institution's storage and software policies before loading a filesystem with data.

## Next Steps

With the structure in place, three investments pay off quickly. First, move from loose scripts to a workflow manager such as Snakemake or Nextflow, which encode multi-step analyses as declarative pipelines with built-in resume behavior. Your `scripts/` and `logs/` directories are already shaped for them. Second, learn container tools such as Apptainer or Docker so tool versions travel with your project rather than living only in your home directory. Third, learn your cluster's scheduler, typically SLURM, so heavy jobs leave the login node and run where they belong. None of these require changing the directory template, which is the point of it.

## Frequently Asked Questions

### What is the best bioinformatics home directory structure for a beginner?

Use one self-contained folder per project under `~/projects/`, with fixed subfolders for raw data, processed data, references, scripts, results, logs, and metadata. Add shared top-level directories for databases (`~/db/`), personal scripts (`~/bin/`), manually installed software (`~/software/`), and disposable files (`~/scratch/`). This structure is small enough to learn in an afternoon and matches the conventions most tools and pipelines expect.

### Should I install software in my home directory or use system modules?

Use the system module system when the tool and version you need is available, because modules are maintained and optimized by administrators. Install into your home directory with conda when you need a version or tool the modules lack, or when you are on a machine you control. Many working setups combine both, with conda environments for niche tools and modules for heavy shared software.

### How do I find out how much space I am using in my home directory?

Run `du -s -h ~` for a single total, or `du -h -d 1 ~` to see the size of each first-level subdirectory, and `quota -s` if your system supports quotas. Repeat the per-directory check whenever an analysis finishes, because intermediate files are where space quietly disappears.

### What belongs in .bashrc versus a project script?

`.bashrc` holds personal, session-level settings that apply everywhere, such as `PATH` additions, history settings, aliases, and prompt configuration. Project-specific variables, tool parameters, and run commands belong in scripts inside the project's `scripts/` folder. The dividing line is simple: if a setting only makes sense for one analysis, it does not belong in `.bashrc`.

### How do I move my setup to a new server or HPC cluster?

Copy four things: your projects folder, your `.bashrc`, your `~/bin` scripts, and a list of the conda environments you need, obtained with `conda env export`. Reinstall conda fresh on the new system with the installer's `-p` option, recreate environments from the export files, and leave large reference data behind in favor of re-downloading or linking it at the new site.

### Do I need conda, or can I install tools with the system package manager?

You can use the system package manager, such as `apt`, but it generally provides one version of each tool for the whole machine and requires administrator rights. Conda installs user-owned, version-pinned, isolated environments without administrator rights, which is why it became the standard for bioinformatics software management on shared systems. On a personal laptop the system package manager is a reasonable complement for general tools.

### Where should large FASTQ and reference files live?

Large files belong on the high-capacity filesystem your institution provides, typically called scratch, work, or project space, and your home directory should reference them through symbolic links created with `ln -s`. Reference databases used by many projects belong once in `~/db/` or on shared storage, never duplicated per project.

### How often should I back up my home directory?

Back up code, configuration, and metadata every time you complete a meaningful unit of work, which in practice means daily during active projects, using an incremental tool such as `rsync`. Verify a restore from the backup occasionally, because a backup that has never been restored is a hope rather than a backup. Large raw data usually does not need personal backups at all if it can be re-obtained from the sequencer or repository, but confirm that with your data provider before counting on it.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the best bioinformatics home directory structure for a beginner?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use one self-contained folder per project under ~/projects/, with fixed subfolders for raw data, processed data, references, scripts, results, logs, and metadata. Add shared top-level directories for databases, personal scripts, manually installed software, and disposable files."
      }
    },
    {
      "@type": "Question",
      "name": "Should I install software in my home directory or use system modules?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use the system module system when the tool and version you need is available. Install into your home directory with conda when you need a version or tool the modules lack, or when you are on a machine you control. Many working setups combine both."
      }
    },
    {
      "@type": "Question",
      "name": "How do I find out how much space I am using in my home directory?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Run du -s -h for a single total, or du -h -d 1 to see the size of each first-level subdirectory, and quota -s if your system supports quotas."
      }
    },
    {
      "@type": "Question",
      "name": "What belongs in .bashrc versus a project script?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": ".bashrc holds personal session-level settings such as PATH additions, history settings, aliases, and prompt configuration. Project-specific variables and run commands belong in scripts inside the project's scripts folder."
      }
    },
    {
      "@type": "Question",
      "name": "How do I move my setup to a new server or HPC cluster?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Copy your projects folder, your .bashrc, your ~/bin scripts, and exported conda environment files. Reinstall conda fresh on the new system, recreate environments from the exports, and re-download or link large reference data at the new site."
      }
    },
    {
      "@type": "Question",
      "name": "Do I need conda, or can I install tools with the system package manager?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "You can use the system package manager, but it generally provides one version of each tool and requires administrator rights. Conda installs user-owned, version-pinned, isolated environments without administrator rights, which is why it is the standard for bioinformatics software on shared systems."
      }
    },
    {
      "@type": "Question",
      "name": "Where should large FASTQ and reference files live?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Large files belong on the high-capacity scratch or project filesystem your institution provides, referenced from your home directory through symbolic links. Shared reference databases belong once in a central location, never duplicated per project."
      }
    },
    {
      "@type": "Question",
      "name": "How often should I back up my home directory?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Back up code, configuration, and metadata daily during active projects using an incremental tool such as rsync, and verify a restore occasionally. Large raw data usually does not need personal backups if it can be re-obtained from the sequencer or repository."
      }
    }
  ]
}
</script>