Linux provides a powerful feature to integrate remote filesystems into your local one. And if you are required to provide this privilege to non-admin users the kernel extention FUSE might be the tool you are looking for.

This article introduces FUSE and describes how to use it and what kind of interfaces are available.

FUSE

Integrating and decoupling file systems is reserved for administrative users by default and supported file systems have to be integrated in the Linux kernel. With FUSE things did change. FUSE allows non-admin users to mount custom file systems. And the file system driver may run in a userspace program. So any user will be able to map (remote) resources into the local file system.

Why FUSE?

Traditionally Unix systems are mapping any system component and their features to the file system. This is a very powerful technique since every single program will be able to access and modify system properties (if there are sufficient permissions) by simply accessing files in the local file system!

To get an idea of this concept we will dicuss a simple example. For instance, imagine you have got an alarm system attached to your Linux box with various connectors for input and output signals. If you are able to map each and every connector to one or many files any program within our system should be able to keep track of the state of monitored devices by simply reading contents of files mapping the state of sensors. Furthermore your programs will be able to control actors by writing to files that are mapping the state of actors. And because of the simplicity of this concept you will be able to implement your alarm system with any programming language you can think of. Even the visualization of the state of your alarm system via web interface should be a cakewalk…

FUSE enables every user to map data and states to the file system, that are accessible to them. For example …

• mounting remote file systems via SSH. So every local application will be able to access remote files as if they would be local ones.
• another example could be a driver that will enable your user to map whole databases to the filesystem, where single files are representing tables; rows within each file are representing datasets.
• our last example is mapping the contents of a software control system via a network connection (e.g. HTTP(s)/WebDAV) to the local file system – in this case simple scripts would be able to perform actions to your repository without the need to checkout any contents in advance.

But FUSE has its limits. Resources that are not supported by your local system and are not reachable directly or via third parties cannot be interfaced.

How Does it Work?

The following picture shows the path of a system call. The program ‘ls’ is accessing contents within your filesystem mounted by FUSE. (it has been borrowed from the hompage of the FUSE project)

As you can see the following is happening:

• Your application ‘ls’ is calling functions within the glibc (GNU C Library).
• The glibc itself is calling functions within the kernel.
• The kernel identifies the FUSE module that will provide the requested information.
• And FUSE is calling the driver running within the userspace.
• In the end the provided data is routed back to the program that did trigger the request.

If you are interested in the backgrounds of kernel programming and the difference between kernel space and userspace you should take a look to the article Driver Development for Linux 2.6.

Language Bindings

To implement a FUSE device driver you are required to utilize a programming language that is able to interface with the FUSE API. However, in the summer of 2010 there are at least 16 programming languages available supporting the FUSE API. The following list provides an overview:

123456789101112131415161718

Supported Language to interface with FUSE:    * C    * C++    * Java    * C#    * Haskell    * TCL    * Python    * Perl    * Sh    * SWIG bindings    * OCaml    * Pliant    * Ruby    * Lua    * Erlang    * PHP 

Supported Operating Systems

FUSE is running on various operating systems. You are not limited to Linux when you are planning to implement new drivers for FUSE. This is a list of supported operating systems:

• Linux 2.4
• Linux 2.6
• FreeBSD
• NetBSD
• MacOS X
• Open Solaris
• GNU HURD

Available Drivers / Filesystems

The list of supported filesystems and available FUSE drivers is growing quickly. Beside the list of approx. 40 different filesystems the list of FUSE drivers is devided into the following categories:

• Archive File Systems – accessing files inside archives (tar, cpio, zip, etc.)
• Compressed File Systems – accessing files in a compressed image (gz, zlib, LiveCDs, etc.)
• Database File Systems – storing files in a relational database (MySQL, BerkeleyDB, etc.) or ones allowing searching using tags or SQL queries
• Encrypted File Systems – storing files in a more secure way by using a secret key
• Media File Systems – storing files on media devices such as cameras and music players or accessing and categorizing media files
• Hardware File Systems – provide access to weird hardware
• Monitoring File Systems – provide notification when a file changes
• Network File Systems – storing files on remote computers, including file servers and web sites
• Non-Native File Systems – traditional disk-based file systems that aren’t standard on Linux (NTFS, ZFS, etc.)
• Union File Systems – merging multiple file systems into a single tree
• Versioning File Systems – file systems that remember old versions of files and ones which provide access to version control systems

For details please refer to the list of file systems available at the home page of the FUSE project.

Related articles:

• Mount Remote Filesystems via SSH
• How to Mount ISO Images
• Mount ISO Images with FUSE
• Mount SMB Shares with FUSE
• Mount Subversion with FUSE
• Mount MySQL with FUSE

Related resources:

• Homepage of FUSE
• List of supported file systems
• FUSE at Wikipedia.org

Incoming search terms:

• linux fuse glibc call