# MooseFS replicates files, and the topic tags say erasure coding

> MooseFS is a POSIX distributed file system in pure C that spreads files across commodity servers with a configurable number of copies. Its topic tags include erasure-coding, while its feature list describes replication and never mentions erasure coding once.

**moosefs/moosefs** — MooseFS Distributed Storage – Open Source, Petabyte, Fault-Tolerant, Highly Performing, Scalable Network Distributed File System / Software-Defined Storage

- Repository: https://github.com/moosefs/moosefs
- Website: https://moosefs.com
- Stars: 2,008 · Forks: 241
- Language: C
- License: GPL-2.0
- Published: 2026-10-12 · Updated: 2026-10-12 · Language: en
- Canonical page: https://hysenlabs.com/projects/moosefs-moosefs

## The features describe replication, the tags say erasure coding

The repository topic list includes erasure-coding, which is not a small thing to claim for a storage system, because erasure coding trades redundancy for space in a way replication does not. The distinctive features list says something different. High reliability is defined as files being stored in several copies on separate servers, with the number of copies a configurable parameter and configurable even per each file. No single point of failure follows from that, and every hardware and software component may be redundant. Nowhere in the features is erasure coding described, and no code path setting or Storage Class is described in those terms. The Storage Classes mechanism is introduced for data tiering, giving different storage policies to different files and directories, and that is a place where a coding scheme could hide. If coding matters to your capacity plan, verify it in the current documentation rather than trusting the tag.

## Three packages, three jobs, one namespace

The minimal package set is three packages and the division of labor is clean. moosefs-master is the master server for metadata, moosefs-chunkserver is the data storage server, and moosefs-client is what mounts the filesystem. What the user sees is a single resource: a hierarchical directory tree with POSIX file attributes including permissions and last access and modification times. On top of that sit ACLs, POSIX and BSD file locks with distributed file locking explicitly named, special files such as block and character devices, pipes and sockets, symbolic links pointing at targets that need not be on MooseFS, and hard links where different names refer to the same data. Deletion is not immediate: files are retained for a configurable period in a file system level trash bin, and coherent atomic snapshots are supported even while files are being written or accessed. Access to the filesystem can be limited by IP address or password in a way comparable to NFS. The newest published build is 4.59.2 from 2026-05-18, alongside block storage provided by mfsbdev, which is a different interface to the same infrastructure.

## The minimal setup starts with copying three sample files

Bringing up a filesystem is described as three steps, and the first one is the master. Install moosefs-master, then as root copy the sample configuration and the sample exports file, cd /etc/mfs followed by copying mfsmaster.cfg.sample to mfsmaster.cfg and mfsexports.cfg.sample to mfsexports.cfg. Next the metadata file is prepared in /var/lib/mfs by copying metadata.mfs.empty to metadata.mfs, chowning it to mfs:mfs and removing the empty original. Then start it with mfsmaster start. One instruction is easy to skip and important: make the machine visible under the mfsmaster name, either through a DNS entry, which the README recommends, or through an /etc/hosts entry added on all servers that run any MooseFS component. Since the chunkservers and clients all resolve that name, getting it wrong means a system that starts but cannot find its own master.

## Chunkservers need storage paths and an mfs:mfs owner

The second step is at least two chunkservers, with more than two strongly recommended, and each one needs three things prepared. Copy mfschunkserver.cfg.sample and mfshdd.cfg.sample into /etc/mfs, then append paths to the disks or partitions that will hold chunks at the end of mfshdd.cfg, one per line. XFS is the recommended underlying filesystem for those chunk locations. Then ownership and permissions are set for each path:

```bash
chown mfs:mfs /mnt/chunks1 /mnt/chunks2 /mnt/chunks3
chmod 770 /mnt/chunks1 /mnt/chunks2 /mnt/chunks3
```

After that the service starts with mfschunkserver start, and the whole sequence repeats for the second, third and subsequent chunkservers. Two is the stated minimum and the recommendation goes higher, which follows directly from how copies are placed: a filesystem that stores each file in several copies needs enough separate places to put them. On the client side, install moosefs-client and mount it, either with mount -t moosefs mfsmaster: /mnt/mfs or with mfsmount -H mfsmaster /mnt/mfs.

## FUSE on Linux and macOS, Dokany on Windows

The client is the piece that determines where the filesystem can be mounted, and the answer differs by platform in an instructive way. On Linux and BSD the client uses the FUSE library, and on macOS it uses macFUSE. On Windows there is a separate MooseFS Client, and it is built on top of Dokany rather than FUSE, with the Dokany repository linked from the README. That split matters when you plan a mixed environment, because the Windows client is not merely the same binary on another operating system. The supported platform list is otherwise broad: any POSIX compliant operating system, with named packaging for Ubuntu, Debian, RHEL and CentOS, Rocky Linux and AlmaLinux, OpenSUSE, Arch Linux, Alpine Linux, FreeBSD and macOS. Debian packages are stated to be compatible with Proxmox and RPM packages with openSUSE Leap, which are the two cases people ask about when the host is not a plain server.

## Build scripts compile but deliberately do not install

Building from source is documented with per-platform scripts, one each for Linux, FreeBSD and macOS. On Linux you run ./linux_build.sh, on FreeBSD ./freebsd_build.sh and on macOS ./macosx_build.sh, with a note that macFUSE must be installed beforehand. What the scripts do not do is install, and the README is explicit that they only build and do not run make install, so installation is a separate manual step as root or with sudo. Dependencies come first. On Debian and Ubuntu the list is build-essential, libpcap-dev, zlib1g-dev, libfuse3-dev and pkg-config, with a libfuse-dev variant for systems without FUSE 3.x; on CentOS, RHEL, Rocky Linux and AlmaLinux it is gcc, make, libpcap-devel, zlib-devel, fuse3-devel and pkgconfig, again with a fuse-devel fallback. fuse3 is listed as a recommended package on both families. The repository layout mirrors the architecture with mfschunkserver/, mfsclient/, mfscommon/, mfsdata/, mfsmaster/ and mfstests/ as directories, plus an autotools build with configure.ac and aclocal.m4.

## Where MooseFS is the wrong tool

Four cases rule it out. The first is a small deployment. A single machine with plenty of disk does not need a distributed filesystem, and the minimum described setup is one master plus at least two chunkservers with more strongly recommended, which is three machines before you have any redundancy. The second is object storage with erasure coding as the goal. The features describe configurable replication and the storage cost of that is a multiple of your data, so a plan that depends on coding economics is checking an assumption the documentation does not back. The third is an application that needs a database, an object API or S3 semantics. This is a POSIX filesystem with a directory tree, block devices, pipes and sockets, which is the right shape for existing software that expects a filesystem and the wrong shape for a cloud-native service that expects keys. The fourth is organizational: metadata lives on the master, and the README describes the metadata file, the sample configuration and making the master's hostname resolvable everywhere. A single master process holding the namespace is a component your operations have to own, whatever the redundancy claims for the hardware.

## Conclusion

MooseFS suits an organization that already runs POSIX storage across many commodity servers and wants one namespace with snapshots, quotas and distributed locking. It does not suit a small deployment where a single server holds the data, since the minimum setup is one master plus at least two chunkservers. Before adopting, decide how many copies each file needs and what that costs, confirm your client platform is on the supported list, and read the metadata backup story before you put production data on a master.

## FAQ

### How many copies of a file does MooseFS keep?

A configurable number of copies on separate servers, and the feature list says the number can be configured per each file. The topic tags mention erasure-coding but the features describe replication.

### Which packages make up a minimal MooseFS install?

moosefs-master for metadata, moosefs-chunkserver for data storage, and moosefs-client to mount the filesystem. At least one master and at least two chunkservers are required, with more than two strongly recommended.

### Does MooseFS work on Windows?

There is a separate MooseFS Client for Microsoft Windows, built on top of Dokany. Linux and BSD clients use FUSE, and the macOS client uses macFUSE.

### What should the chunk storage be formatted with?

XFS is the recommended underlying filesystem for disks designated to store chunks. Each chunk path also needs ownership set to mfs:mfs and permissions of 770.

### Do the build scripts install MooseFS for me?

No. The scripts only build, and the README says explicitly that they do not run make install. Installation is a separate manual step as root or with sudo make install.

### Does MooseFS support snapshots and file locking?

Coherent atomic snapshots are supported even while files are being written or accessed, and POSIX and BSD file locks including distributed file locking are listed. Deleted files are retained for a configurable period as a filesystem level trash bin.

## Sources

- [License: GPL-2.0](https://github.com/moosefs/moosefs/blob/master/LICENSE)
- [moosefs/moosefs on GitHub](https://github.com/moosefs/moosefs)
- [Project website](https://moosefs.com)
- [README](https://github.com/moosefs/moosefs/blob/master/README.md)
- [Releases](https://github.com/moosefs/moosefs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/moosefs-moosefs