MooseFS

In the Azure Portal, open the Marketplace, search for MooseFS, select the SecureAnyCloud publisher entry, and select Create.

On the Networking tab, attach a network security group that allows inbound TCP 22 from your management IP range and TCP 443 (the web monitor) from your admin networks. You do not need to open any MooseFS protocol port, because the image binds them to loopback or firewalls them to this machine.

Select Review + create, wait for validation, then select Create. Deployment takes around two minutes.

Connect over SSH using the key you supplied at deployment:

ssh azureuser@<vm-ip>

Confirm that every MooseFS component and the TLS front are active:

sudo systemctl is-active moosefs-master moosefs-chunkserver moosefs-gui moosefs-mount nginx

Expected output: five lines, all active.

active active active active active

Confirm the listening sockets. The client control port and the web monitor are on loopback, and only nginx is published:

sudo ss -H -lnt "( sport = :9421 or sport = :9425 or sport = :443 )" | awk '{print $4}'

Expected output:

127.0.0.1:9421 127.0.0.1:9425 0.0.0.0:443

First boot generates the web monitor password on this virtual machine and writes it to a root-only file. List the file:

sudo ls -l /root/moosefs-credentials.txt

Expected output: mode 0600, owned by root.

-rw------- 1 root root 1322 Jul 19 23:34 /root/moosefs-credentials.txt

View the credential keys. The file also records the monitor URL and the mount point.

sudo grep -o '^[A-Z_]*=' /root/moosefs-credentials.txt

Expected output:

GUI_USER= GUI_PASSWORD= <set-at-first-boot>= MOOSEFS_MOUNT_POINT=

Read the full file when you need the actual values.

sudo cat /root/moosefs-credentials.txt

Confirm the MooseFS version:

sudo mfsmaster -v

Expected output:

version: 4.59.2-1 ; build: 2106

Note on the monitor URL. Azure Instance Metadata returns an empty public-IP field for Standard SKU addresses, so MOOSEFS_MONITOR_URL may show this machine's private address. If you connect from outside the virtual network, substitute the public IP shown on the virtual machine's Overview blade in the Azure portal. The monitor is served on port 443 either way.

The MooseFS volume is already mounted. Confirm that it is a genuine MooseFS mount rather than an ordinary directory. The source is mfs# followed by the master address:

findmnt -no SOURCE,FSTYPE,TARGET /srv/moosefs

Expected output:

mfs#127.0.0.1:9421 fuse /srv/moosefs

Write a file and read it back, then verify that the content survived the round trip byte for byte:

sudo mkdir -p /srv/moosefs/demo head -c 4194304 /dev/urandom > ~/demo.bin
sudo cp ~/demo.bin /srv/moosefs/demo/demo.bin sync
sudo sha256sum ~/demo.bin /srv/moosefs/demo/demo.bin

Expected output: the two checksums are identical.

369cd7031892eabed30550a0e2c5c979d660fbbbda357fa223209246f5949851 /home/azureuser/demo.bin 369cd7031892eabed30550a0e2c5c979d660fbbbda357fa223209246f5949851 /srv/moosefs/demo/demo.bin

Confirm that the data is stored as MooseFS chunks, and see which chunkserver holds each copy:

sudo mfsfileinfo /srv/moosefs/demo/demo.bin

Expected output:

/srv/moosefs/demo/demo.bin: chunk 0: 000000000000000F_00000001 / (id:15 ver:1) ; mtime:1784504501 (2026-07-19 23:41:41) copy 1: 10.0.0.28:9422 ; status:VALID

copy 1 is the single copy of this chunk on the single chunkserver. On a multi-node cluster, you also see copy 2, copy 3 and so on.

List the registered chunkservers:

sudo mfscli -H 127.0.0.1 -SCS

Confirm the capacity of the MooseFS volume and of the dedicated data disk beneath it.

df -h /srv/moosefs /var/lib/mfs

Expected output:

Filesystem Size Used Avail Use% Mounted on mfs#127.0.0.1:9421 38G 302M 37G 1% /srv/moosefs /dev/sda 40G 46M 38G 1% /var/lib/mfs

The chunks themselves live on the dedicated data volume:

sudo find /var/lib/mfs/chunks -name 'chunk_*.mfs' -type f > ~/mfs-chunks.txt head -3 ~/mfs-chunks.txt

Browse to https://<vm-ip>/ and sign in with the GUI_USER and GUI_PASSWORD values from /root/moosefs-credentials.txt. The certificate is self-signed and bound to this virtual machine, so your browser warns you on the first visit.

From the command line, verify that the monitor refuses anonymous access and accepts the per-VM credential:

curl -k -s -o /dev/null -w 'anonymous: %{http_code}\n' https://127.0.0.1/
curl -k -s -o /dev/null -w 'authenticated: %{http_code}\n' -u '<GUI_USER>:<GUI_PASSWORD>' https://127.0.0.1/mfs.cgi

Expected output:

anonymous: 401 authenticated: 200

The Info tab shows the cluster summary: master version and state, total and available space, and the file and chunk counts.

Why the chunk matrix shows chunks as "endangered". On the Info tab, the redundancy matrix reports every chunk at redundancy level 0 and colours the count orange. This is correct and expected on a single-node cluster. With one chunkserver there is exactly one copy of each chunk, so MooseFS is reporting accurately that no chunk could survive losing that server. The indicator turns green once you add a second chunkserver and raise the goal, as described in Step 7.

The Chunkservers tab lists each registered chunkserver with its address, version, chunk count, and used and total space.

The Disks tab shows the individual storage directories behind each chunkserver. Here it shows the chunk directory on the dedicated data volume, with its chunk count, error status and capacity.

The Exports tab shows which clients may mount the filesystem. Both entries are restricted to 127.0.0.1, which is the loopback-only export policy this image ships with.

Genuine fault tolerance needs chunkservers on separate virtual machines, so that losing one machine cannot lose the only copy of a chunk. The outline below is the standard MooseFS procedure. Apply your own network and security review before you use it in production.

On this master virtual machine, allow the new chunkserver's private address through the nftables guard:

sudo nft insert rule inet sac_moosefs input ip saddr <chunkserver-private-ip> tcp dport 9420 accept

Persist that rule by adding it to /etc/nftables.d/moosefs.nft above the drop rule. Also allow TCP 9420 from the new machine in your Azure network security group.

On each new virtual machine, install the chunkserver from the same official repository. Point MASTER_HOST in /etc/mfs/mfschunkserver.cfg at this master's private address, list its storage directories in /etc/mfs/mfshdd.cfg, then start moosefs-chunkserver.

Once the new chunkservers appear on the Chunkservers tab, raise the storage goal so that MooseFS keeps more than one copy of each chunk:

sudo mfssetgoal -r 2 /srv/moosefs

MooseFS then replicates existing chunks in the background until every chunk meets the new goal, and the redundancy matrix on the Info tab turns green.

To mount the filesystem from other machines, you must also widen the export list. Add an entry to /etc/mfs/mfsexports.cfg scoped to the specific client network and protected with a password. Then widen MATOCL_LISTEN_HOST in /etc/mfs/mfsmaster.cfg from 127.0.0.1 to the private address, and open port 9421 to those clients only:

10.0.0.0/24 / rw,alldirs,maproot=0,password=<your-secret>

Reload the master to apply the export changes:

sudo mfsmaster reload

Do not widen MATOCL_LISTEN_HOST without setting a password. The client control port grants access to the whole filesystem, which is why this image keeps it on loopback by default.

The master's metadata is the index of the entire filesystem. If you lose it, the chunks are unusable. The metadata lives on the dedicated data volume at /var/lib/mfs:

sudo ls -l /var/lib/mfs/metadata.mfs.back /var/lib/mfs/metadata.crc

While the master is running, the current metadata image on disk is metadata.mfs.back, accompanied by the changelog.*.mfs files that hold changes since the last save. A plain metadata.mfs appears only while the master is cleanly stopped, so do not treat its absence on a running system as a fault.

For production, run a moosefs-metalogger on a separate machine. The metalogger keeps a continuously updated copy of the master metadata and is the supported way to recover a failed master.

This image binds the metalogger port (9419) to loopback. Widen MATOML_LISTEN_HOST in /etc/mfs/mfsmaster.cfg and allow 9419 from the metalogger's address only, as for the chunkserver in Step 7.

Azure disk snapshots of the data volume are a useful complement. Take them consistently, and treat them as a point-in-time copy rather than a substitute for a metalogger.

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for MooseFS. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that allows inbound port 22 from your management network and inbound port 443 from where you will reach the web monitor. Leave the root volume at the default size or larger; the image adds a separate 40 GiB data volume for the MooseFS metadata and chunk storage automatically.

Select Launch instance. First boot initialisation takes under a minute after the instance state becomes Running and the status checks pass.

The following block launches an instance from the SecureAnyCloud MooseFS Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens port 22 and port 443 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":20,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=moosefs-01}]'

The command prints a JSON document on success. Note the instance ID, then retrieve its public address once it is running with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

On the first boot of the instance, moosefs-firstboot.service generates a per instance web monitor password, regenerates a TLS certificate bound to the instance, brings the MooseFS stack up, mounts the filesystem, and writes the credentials to /root/moosefs-credentials.txt (readable only by root). Connect over SSH and read that file:

ssh <login-user>@<public-ip>
sudo cat /root/moosefs-credentials.txt

The file contains GUI_USER, GUI_PASSWORD, MOOSEFS_MONITOR_URL (the https://<instance-public-ip>/ address of the web monitor) and MOOSEFS_MOUNT_POINT (/srv/moosefs). Note the user and password for the next step.

Open the MOOSEFS_MONITOR_URL from the credentials file in a browser, for example https://<public-ip>/. The certificate is self signed and bound to the instance, so your browser warns on the first visit; accept the warning to continue. When prompted for HTTP Basic Auth, sign in with the GUI_USER and GUI_PASSWORD values from the credentials file.

The monitor opens on the Status dashboard, showing total and free space, cluster health, usage and live throughput for the master server and the chunkserver.

The Info tab shows the cluster summary, the master metadata server and the chunk redundancy matrix. On a fresh single node instance you will see the health reported as "all in danger" and chunks at redundancy level 1 (RL=1): this is expected and simply means every chunk currently has a single copy because there is one chunkserver. It is not an error; see the last section for how to add redundancy.

The Chunkservers tab lists each chunkserver with its version, chunk count and the used and total space on the dedicated data volume.

The Mounts tab shows the active MooseFS FUSE client mounted at /srv/moosefs, ready to read and write files.

From an SSH session on the instance, confirm every service is running:

systemctl is-active moosefs-master moosefs-chunkserver moosefs-gui moosefs-mount nginx

Confirm the web monitor backend answers on the loopback interface and the MooseFS filesystem is mounted:

curl -sS -o /dev/null -w 'monitor backend HTTP %{http_code}\n' http://127.0.0.1:9425/mfs.cgi findmnt --noheadings --output SOURCE,FSTYPE,TARGET /srv/moosefs

The mount source reads mfs#127.0.0.1:9421 with filesystem type fuse, which confirms the mount is genuinely MooseFS and not an ordinary directory. Inspect the cluster with the MooseFS command line client, which talks to the master on loopback:

mfscli -H 127.0.0.1 -SIN mfscli -H 127.0.0.1 -SCS

-SIN prints the cluster information summary and -SCS lists the chunkservers with their state and free space.

The MooseFS volume at /srv/moosefs behaves like any other directory. Write a file, read it back, and confirm the bytes really landed in MooseFS chunk storage:

echo "hello from sac MooseFS" > /srv/moosefs/hello.txt cat /srv/moosefs/hello.txt mfsfileinfo /srv/moosefs/hello.txt rm -f /srv/moosefs/hello.txt

mfsfileinfo reports the chunk backing the file and the chunkserver copy holding it (copy 1: with status:VALID). Applications write to /srv/moosefs exactly as they would to a local path; MooseFS transparently stores the data as distributed chunks. To make the volume available to other machines you widen the MooseFS export list and open the chunkserver port to those peers, which is the same operation as adding a chunkserver described below.