FUSE

FUSE: Filesystem in Userspace. The interface that lets non-privileged users create their own file systems without editing kernel code; a "bridge" to the actual kernel interfaces. E.g. GlusterFS, GmailFS.

In other words, FUSE is a framework that allows you to create a fully functional filesystem that runs as a regular program in user space, instead of having to write complex code that runs inside the operating system's kernel.

How FUSE Works: The Technical Breakdown

FUSE consists of two main components:

1. The FUSE Kernel Module (fuse.ko): This is the only part that runs in kernel space. It's a generic, stable piece of code that acts as a "pass-through." It registers a new virtual filesystem with the kernel's VFS (Virtual File System) layer. When the kernel receives a filesystem operation for this new mount point (like open, read, write, readdir), it doesn't handle it itself. Instead, it packages up the request and sends it to your user-space program via the /dev/fuse character device, which then processes the request and sends a reply back down to the kernel.
2. The User-Space Daemon (Your Program): This is the program you write. It links against the libfuse library (https://github.com/libfuse/libfuse). This library handles the communication with the FUSE kernel module. Your program's main job is to implement a set of standard filesystem callbacks, such as:
   • fuse_operations.getattr: Called when the kernel wants file attributes (size, permissions, etc.).
   • fuse_operations.readdir: Called when the kernel wants to list the contents of a directory.
   • fuse_operations.open: Called when a file is opened.
   • fuse_operations.read: Called when data is read from an open file.
   • fuse_operations.write: Called when data is written to a file.

The Workflow:

1. A user runs ls /my/fuse/mount.
2. The kernel's VFS sees this is a FUSE mount and passes the readdir request to the FUSE kernel module.
3. The FUSE kernel module sends the request to your user-space daemon.
4. Your program's readdir function is executed. It might connect to an API, query a database, or just look at a local directory to figure out the contents.
5. Your program constructs the directory listing and sends it back to the kernel module via libfuse.
6. The kernel module passes the data back to the ls command, which prints the directory listing to the screen.

To the ls command (and every other program on the system), /my/fuse/mount looks and behaves exactly like any other regular directory.

Why FUSE?

1. Safety and Stability: Since your filesystem logic runs in user space, a bug in your code will only crash your program, not the entire operating system kernel. This makes development infinitely safer and easier.
2. Ease of Development: You can write a FUSE filesystem in almost any high-level language (Python is very popular for this), using standard libraries and tools. You don't need to learn kernel programming.
3. Incredible Flexibility: FUSE unshackles the concept of a "filesystem" from a physical disk. A FUSE filesystem can be backed by almost anything.

FUSE examples

Cloud Storage Filesystems (Most Common Use Case)

These tools mount a remote cloud storage bucket as if it were a local folder on your machine. This is extremely useful for scripts, applications, and users who need to interact with cloud storage using standard file operations (ls, cp, rm, etc.).

• gcsfuse (Google Cloud Storage)
  • What it does: Mounts a Google Cloud Storage (GCS) bucket. You can ls your objects, cat a text file directly from the bucket, or even cp a file into the directory to upload it.
  • Use case: Accessing training data for a machine learning model, managing website assets, or providing a simple user interface to a GCS bucket.
• s3fs-fuse (Amazon S3)
  • What it does: The equivalent of gcsfuse for Amazon S3. It lets you mount an S3 bucket as a local filesystem.
  • Use case: Very popular for legacy applications that were designed to work with a local file system but now need to store their data in S3.
• rclone mount
  • What it does: Rclone is the "Swiss Army knife" of cloud storage. Its mount command uses FUSE to mount dozens of different cloud storage providers (Dropbox, Google Drive, OneDrive, S3, GCS, etc.) as a local directory.
  • Use case: A unified way to interact with all your different cloud storage accounts through your file manager.

Docker images

docker-image-fuser (Standalone Tool): This is a specific, purpose-built tool that does exactly what its name implies.

• How it Works: You point it to a Docker image (either a local one or one in a remote registry), and it creates a FUSE mount point. When you ls or cd into that mount point, you are seeing the fully composed, final filesystem of the container image, with all the layers merged together.
• Key Features:
  • It can mount images directly from remote registries without pulling them completely. It only fetches the necessary metadata and layer blobs on demand.
  • It's read-only, which is a crucial safety feature. You are inspecting the image, not changing it.
• Use Case: You need to quickly grab a single configuration file from a large image, or you want to run a security scanner (like trivy or grype) on the image's filesystem without the overhead of running a container.

Example Command:

# First, create a mount point directory
mkdir /tmp/my_image_mount

# Mount a remote image
docker-image-fuser -i nginx:latest -t registry.hub.docker.com /tmp/my_image_mount

# Now you can explore it like a regular directory
ls -l /tmp/my_image_mount/etc/nginx/
cat /tmp/my_image_mount/etc/nginx/nginx.conf

skopeo mount (Part of the Skopeo Toolset): Skopeo is a powerful command-line utility for working with container images and registries. One of its lesser-known but very useful features is skopeo mount.

• How it Works: Skopeo uses FUSE to mount the layers of a container image from a registry in a read-only fashion.
• Key Features:
  • It's part of a larger, well-maintained suite of container tools (from the same family as Podman and Buildah).
  • It's excellent for low-level inspection and debugging of image layers.
• Use Case: Similar to docker-image-fuser, it's great for inspection and analysis. If you're already using other tools from the container ecosystem like Podman, Skopeo is a natural fit.

Example Command:

mkdir /tmp/skopeo_mount
skopeo mount containers-storage:your-local-image-id /tmp/skopeo_mount
# Or from a remote registry
skopeo mount docker://docker.io/library/alpine /tmp/skopeo_mount

crfs (Container Registry Filesystem): This is another great FUSE implementation specifically designed for container registries.

• How it Works: It mounts an entire container registry (or a specific repository within it) as a filesystem. The directories represent the repositories and tags, and the files inside represent the image layers and manifest.
• Key Features:
  • Mounts the entire registry, not just a single image.
  • Presents the image in a "decomposed" way, showing you the manifest and individual layer blobs.
• Use Case: This is more for developers or security researchers who need to do a deep dive into the structure of images within a registry, rather than just inspecting the final filesystem.

Remote Server & Network Filesystems

These mount filesystems from other computers over a network.

• SSHFS (SSH Filesystem)
  • What it does: This is a classic and incredibly useful FUSE filesystem. It mounts a directory from a remote server onto your local machine using nothing but an SSH connection.
  • Use case: You want to edit files on your web server using your favorite local code editor (like VS Code) without having to constantly scp or sftp them back and forth. You just sshfs user@remote-server:/path/to/project ~/my-remote-project and edit the files directly.

Archive & Image Filesystems

These let you peek inside compressed archives or disk images without extracting them.

• fuse-zip
  • What it does: Mounts a .zip file as a directory. You can browse the contents, read files, and copy them out, all without decompressing the entire archive.
• archivemount
  • What it does: A more powerful version that can handle various archive types, like .tar.gz and .tar.bz2.
• fuseiso
  • What it does: Mounts an .iso, .img, or .nrg disk image file, which is very useful for accessing the contents of CD/DVD images.

Version Control Filesystems

These expose a version control system's history or state as a filesystem.

• git-fs
  • What it does: Mounts a Git repository. The mounted directory can expose different branches, commits, and tags as subdirectories, allowing you to browse the entire history of your project as if it were a set of snapshots in your file manager.

Fun, Creative, and "Weird" Filesystems

These examples truly showcase the "you can represent anything as a filesystem" power of FUSE.

• wikipediafs
  • What it does: Mounts Wikipedia as a filesystem. You can cd into a directory named after a language (e.g., en), and you'll see files named after every article. When you cat an article file, it fetches the content from Wikipedia and displays it. Editing the file could even (in theory) update the article.
• gmailfs (historical, but a great concept)
  • What it does: An older project that mounted your Gmail inbox as a filesystem. Directories represented email labels, and emails themselves were represented as text files containing the message content and headers.
• EncFS / gocryptfs
  • What it does: These are encrypted filesystems. They work by encrypting files on-the-fly. You have a "raw" (encrypted) directory and a "mount point" (decrypted) directory. Any file you write to the mount point is automatically encrypted and stored in the raw directory. This is a great way to store sensitive files in an untrusted location like a cloud storage folder.
• ifuse
  • What it does: Allows you to mount the filesystem of an iPhone or iPad on a Linux machine, giving you access to the device's documents and media.

These examples show that with FUSE, the concept of a "file" or "directory" is completely abstract. It's just a user-friendly interface to any data source you can imagine.