Introduction

Navigating the Linux filesystem hierarchy can be a daunting task for newcomers and even seasoned administrators. Unlike some other operating systems, Linux follows a unique directory structure that is both systematic and crucial for system management and operation. Understanding this structure is essential for efficient system administration, troubleshooting, and software management. In this article, we’ll dive deep into the Linux filesystem hierarchy, exploring each directory’s purpose and significance.

The Root Directory (/)

At the pinnacle of the Linux filesystem hierarchy is the root directory, denoted by a single forward slash (/). This directory is the starting point from which all other directories branch out. Think of it as the base of a tree, with all other directories extending from it.

The root directory is essential for the operating system’s overall structure, providing the foundation upon which the entire filesystem is built. All files and directories, regardless of their location, can ultimately be traced back to the root directory.

Key Directories and Their Purposes

Understanding the primary directories within the Linux filesystem is crucial for effective navigation and management. Here’s a detailed look at each significant directory:

/bin

Purpose: The /bin directory houses essential binary executables that are necessary for the system to function correctly, even in single-user mode. These binaries are crucial for basic system operations and recovery.
Examples: Common commands found here include ls (list directory contents), cp (copy files), and rm (remove files). These utilities are used by both system administrators and regular users.

/sbin

Purpose: Similar to /bin, the /sbin directory contains system binaries, but these are primarily administrative commands used for system maintenance and configuration. These binaries are typically used by the root user or system administrators.
Examples: Commands such as fsck (filesystem check), reboot (reboot the system), and ifconfig (network interface configuration) are located here.

/etc

You may want to set up a file server like FileRun for any number of reasons. The main reason, I would think, would be so you can have your own Google Drive alternative that is under your control instead of Google’s.

FileRun claims to be “Probably the best File Manager in the world with desktop Sync and File Sharing,” but I think you’ll have to be the judge of that for yourself.

Just to be completely transparent here, I like FileRun, but there is a shortcoming that I hope they will eventually fix. That shortcoming is that there are some, in my opinion, very important settings that are locked away behind an Enterprise Licence requirement.

That aside, I really like the ease-of-use and flexibility of FileRun. So let’s take a look at it.

Prerequisites for FileRun in Docker

First things first, you’ll need a Docker server set up. Linode has made that process very simple and you can set one up for just a few bucks a month and can add a private IP address (for free) and backups for just a couple bucks more per month.

Another thing you’ll need is a domain name, which you can buy from almost anywhere online for a wide range of prices depending on where you make your purchase. Be sure to point the domains DNS settings to point to Linode. You can find more information about that here: https://www.linode.com/docs/guides/dns-manager/

You’ll also want a reverse proxy set up on your Docker Server so that you can do things like route traffic and manage SSLs on your server. I made a video about the process of setting up a Docker server with Portainer and a reverse proxy called Nginx Proxy Manager that you can check out here: https://www.youtube.com/watch?v=7oUjfsaR0NU

Once you’ve got your Docker server set up, you can begin the process of setting up your VaultWarden password manager on that server.

There are 2 primary ways you can do this:

In the command line via SSH.
In Portainer via the Portainer dashboard.

We’re going to take a look at how to do this in Portainer so that we can have a user interface to work with.

Head over to http://your-server-ip-address:9000 and get logged into Portainer with the credentials we setup in our previous post/video.

On the left side of the screen, we’re going to click the “Stacks” link and then, on the next page, click the “+ Add stack” buton.

This will bring up a page where you’ll enter the name of the stack. Below that that you can then copy and paste the following:

Overview

One of my favorite utilities on the Linux command-line, and block storage is one of my favorite features on Linode’s platform, so in this article I get to combine both of these together – because what I’m going to be doing is show you how to use rsync to copy data from one server to another, in the form of a backup. What’s really cool about this, is that this example will utilize block storage.

Note: I’ll be using the Nextcloud server that was set up in a previous article, but it doesn’t really matter if it’s Nextcloud – you can back up any server that you’d like.

Setting up our environment

On the Linode dashboard, I created an instance named “backup-server” to use as the example here. On your side, be sure to have a Linode instance ready to go in order to have a destination to copy your files to. Also, create a block storage volume to hold the backup files. If you don’t already have block storage set up, you can check out other articles and videos on Linode’s documentation and YouTube channel respectively, to see an overview of the process.

Again, in the examples, I’m going to be backing up a Nextcloud instance, but feel free to back up any server you may have set up – just be sure to update the paths accordingly to ensure everything matches your environment. In the Nextcloud video, I set up the data volume onto a block storage volume, so block storage is used at both ends.

First, let’s create a new directory where we will mount our block storage volume on the backup server. I decided to use /mnt/backup-data:

sudo mkdir /mnt/backup-data

Since the backup server I used in the example stores backups for more than one Linode instance, I decided to have each server back up to a sub-directory within the /mnt/backup-data directory.

sudo mkdir /mnt/backup-data/nextcloud.learnlinux.cloud

Note: I like to name the sub-directories after the fully qualified domain name for that instance, but that is not required.

Continuing, let’s make sure our local user (or a backup user) owns the destination directory:

sudo chown jay:jay /mnt/backup-data/nextcloud.learnlinux.cloud

After running that command, the user and group you specify will become the owner of the target directory, as well as everything underneath it (due to the -R option).

Note: Be sure to update the username, group name, and directory names to match your environment.

Overview

In a previous article, I showed you how to build your very own Nextcloud server. In this article, we’re going to extend the storage for our Nextcloud instance by utilizing block storage. To follow along, you’ll either need your own Nextcloud server to extend, or perhaps you can add block storage to a different type of server you may control, which would mean you’d need to update the paths accordingly as we go along. Block storage is incredibly useful, so we’ll definitely want to take advantage of this.

Let’s begin!

Setting up the block storage volume

First, use SSH to log in to your Nextcloud instance:

ssh

If we execute df -h, we can see the current list of attached storage volumes:

df -h

One of the benefits of block storage, is that you can have a smaller instance (but still have a bigger disk). Right now, unless you’re working ahead, we won’t have a block storage volume attached yet, so create one within the Linode dashboard.

You can do this by clicking on “Volumes” within the dashboard, and then you can get started with the process. Fill out each of the fields while creating the block storage device. But pay special attention to the region – you want to set this to be the same region that your Linode instance is in.

After creating the volume, you should see some example commands that give you everything you need to set up the volume. The first command, the one we will use to format the volume, we can copy and paste that command directly into a command shell. For example, it might look similar to this:

sudo mkfs.ext4 “/dev/disk/by-id/scsi-0Linode_Volume_nextcloud-data”

Of course, that’s just an example command, it’s best to use the command provided from the Linode dashboard, so if you’d like to copy and paste – use the command that you’re provided within the dashboard.

At this point, the volume will be formatted, but we’ll need to mount it in order to start using it. The second command presented in the dashboard will end up creating a directory into which to mount the volume:

sudo mkdir “/mnt/nextcloud-data”

The third command will actually mount the new volume to your filesystem. Be sure to use the command from the dashboard, the one below is presented only as an example of what that generally looks like:

sudo mount “/dev/disk/by-id/scsi-0Linode_Volume_nextcloud-data”

Next, check the output of the df command and ensure the new volume is listed within the output:

df -h

Next, let’s make sure we update /etc/fstab for the new volume, to ensure that it’s automatically mounted every time the server starts up:

Introduction, and Getting Started

Nextcloud is a powerful productivity platform that gives you access to some amazing features, such as collaborative editing, cloud file sync, private audio/video chat, email, calendar, and more! Best of all, Nextcloud is under your control and is completely customizable. In this article, we’re going to be setting up our very own Nextcloud server on Linode. Alternatively, you can also spin up a Nextcloud server by utilizing the Linode marketplace, which you can use to set up Nextcloud in a single click. However, this article will walk you through the manual installation method. While this method has more steps, by the end you’d have built your very own Nextcloud server from scratch, which will be not only a valuable learning experience – you’ll become intimately familiar with the process of setting up Nextcloud. Let’s get started!

In order to install Nextcloud, we’ll need a Linux instance to install it onto. That’s the easy part – there’s no shortage of Linux on Linode, so what we’ll do in order to get started, is create a brand-new Ubuntu 20.04 Linode instance to serve as our base. Many of the commands we’ll be using have changed since Ubuntu 20.04, so while you might be tempted to start with a newer instance, these commands were all tested on Ubuntu 20.04. And considering that Ubuntu 20.04 is supported until April of 2025, it’s not a bad choice at all.

Creating your instance

During the process of creating your new Linode instance, choose a region that’s closest to you geographically (or close to your target audience). For the instance type, be sure to choose a plan with 2GB of RAM (preferably 4GB). You can always increase the plan later, should you need to do so. You can save some additional money by choosing an instance from the Shared CPU section. For the label, give it a label that matches the designated purpose for the instance. A good name might be something like “nextcloud”, but if you have a domain for you instance, you an use that as the name as well.

Continuing, you can consider using tags, which are basically basically a name value pair you can add to your instance. This is completely optional, but you could create whatever tags for your instance if you have a need to do so. For example, you could have a “production” tag, or maybe a “development” tag depending on whether or not you intend to use the instance for production. Again, this is optional, and there’s no right or wrong way to tag an instance. If in doubt, you can just leave this blank.

Next, the root password should be unique, and preferably, randomly-generated. This password in particular is going to be the password we will use to log into our instance so make sure you remember it. SSH keys are preferred, and if you have one set up within your profile, you can check a box on this page to add it to your instance.