mfsexports.cfg(5)

✨ mfsexports.cfg ✨ (section 5 β€” this is part of MooseFS)

okay bestie, gather round, because this file is literally the bouncer at the club for your MooseFS mount points πŸ’…


🌸 NAME 🌸

mfsexports.cfg β€” MooseFS access control for mfsmounts


πŸ¦‹ DESCRIPTION πŸ¦‹

The file mfsexports.cfg is where MooseFS keeps its access list for mfsmount clients. That's it. That's the whole vibe. It's the guest list. No invite, no mount. 🚫


πŸ’– SYNTAX πŸ’–

The syntax is, iconic and simple:

ADDRESS DIRECTORY [OPTIONS]

Lines that start with the # character are ignored as comments β€” so go off, leave yourself lil notes, nobody's reading them but you. πŸŽ€

ADDRESS can show up in a bunch of forms, and yes you pick one:

  • * β€” all addresses (everyone's invited, the whole timeline)
  • n.n.n.n β€” single IP address
  • n.n.n.n/b β€” IP class specified by network address and number of significant bits
  • n.n.n.n/m.m.m.m β€” IP class specified by network address and mask
  • f.f.f.f-t.t.t.t β€” IP range specified by from-to addresses (inclusive)

DIRECTORY can be / or a path relative to the MooseFS root. And there's a special value . β€” that one means the MFSMETA companion filesystem. (not me knowing the secret handshake 🀫)


πŸ‘‘ OPTIONS πŸ‘‘

Here's the whole menu, no skips, fr fr:

  • ro, readonly β€” export tree in read-only mode; this is default (look but don't touch energy, and it's literally the default)
  • rw, readwrite β€” export tree in read-write mode
  • alldirs β€” allows to mount any subdirectory of specified directory (similarly to NFS)
  • dynamicip β€” allows reconnecting of already authenticated client from any IP address (the default is to check IP address on reconnect)
  • ignoregid β€” disable testing of group access at mfsmaster level (it's still done at mfsmount level) β€” in this case "group" and "other" permissions are logically added; needed for supplementary groups to work (mfsmaster receives only user primary group information)
  • admin β€” administrative privileges, and that means:
    • changing quota values
    • storage classes management - adding, deleting, modifying
    • patterns management - adding, deleting
    • using storage classes with admin flag (setting, overwriting)
    • manipulating UNDELETABLE, APPENDONLY and IMMUTABLE flags in filesystem objects
  • maproot=USER[:GROUP] β€” maps root (uid=0) accesses to given user and group (similarly to maproot option in NFS mounts); USER and GROUP can be given either as name or number; if no group is specified, USER's primary group is used. Names are resolved on mfsmaster side (see note below).
  • mapall=USER[:GROUP] β€” like above but maps all non privileged users (uid!=0) accesses to given user and group (see notes below).
  • umask=0### β€” this umask is added (OR) to user's umask and the resulting umask is used in this mount point
  • sclassgroups=-|N[:N[:...]] β€” if this option is not defined, any storage class can be set by user in this mount point, if it is defined, only storage classes belonging to listed groups can be set; to define no groups (user cannot set any storage class) use - (minus) sign; for explanation on how to add a storage class to a group see mfsscadmin(1); for more detailed explanation see STORAGE CLASS GROUPS
  • password=PASS, md5pass=MD5 β€” requires password authentication in order to access specified resource
  • minversion=VER β€” rejects access from clients older than specified
  • mintrashretention=TIME, maxtrashretention=TIME β€” specify range in which trash retention can be set by users
  • mintrashtime=TDUR, maxtrashtime=TDUR β€” deprecated options (function similalry as above)
  • disable=OPERATION[:OPERATION[:...]] β€” do not allow the client to perform certain operations

Default options are: ro, maproot=999:999, mintrashretention=0, maxtrashretention=4294967295.

Note! Default value for maxtrashretention is impossible to be set by user, so if the value is not set, then it can be considered close to infinity, but if it is set, then the maximum is 65535 hours (~390 weeks). πŸ‘€

πŸ’œ NOTES πŸ’œ

USER and GROUP names (if not specified by explicit uid/gid number) are resolved on mfsmaster host.

TDUR (deprecated) can be specified as number without time unit (number of seconds) or combination of numbers with time units. Time units are: W,D,H,M,S. Order is important - less significant time units can't be defined before more significant time units.

TIME can be specified as a number of hours (integer) or as a time period in one of two possible formats: first format: #.#T where T is one of: h-hours, d-days or w-weeks; fractions of minimum unit will be rounded to integer value; second format: #w#d#h, any number of definitions can be omitted, but the remaining definitions must be in order (so #w#h is still a valid definition, but #h#w is not); ranges: h: 0 to 23, d: 0 to 6, w is unlimited and the first definition is also always unlimited (i.e. for #d#h d will be unlimited)

Time units/periods are case insensitive.

Option mapall works in MooseFS in different way than in NFS, because MooseFS is using FUSE's "default_permissions" option. When mapall option is used, users see all objects with uid equal to mapped uid as their own and all other as root's objects. Similarly objects with gid equal to mapped gid are seen as objects with current user's primary group and all other objects as objects with group 0 (usually wheel). With mapall option set attribute cache in kernel is always turned off.

Option disable can take many parameters (operations to disable) in two ways: as a list separated by colons (:) or by repeating the option many times. List of operations that can be disabled:

  • chown β€” don't allow the client to perform the chown operation
  • chmod β€” don't allow the client to perform the chmod operation
  • symlink β€” don't allow the client to create symbolic links
  • mkfifo β€” don't allow the client to create FIFOs
  • mkdev β€” don't allow the client to create devices
  • mksock β€” don't allow the client to create sockets
  • mkdir β€” don't allow the client to create directories
  • unlink β€” don't allow the client to remove non directory objects (will also deny move/rename operation if target inode already exists!)
  • rmdir β€” don't allow the client to remove directories (will also deny move/rename operation if target inode already exists!)
  • rename β€” don't allow the client to change inodes (files, directories) names
  • move β€” don't allow the client to move inodes (files, directories) to another path
  • link β€” don't allow the client to create hard links
  • create β€” don't allow the client to create new files
  • readdir β€” don't allow the client to list directories ('ls' command will not work)
  • read β€” don't allow the client to read from files
  • write β€” don't allow the client to write to files
  • truncate β€” don't allow the client to shorten the length of a file with truncate command
  • setlength β€” don't allow the client to increase the length of a file with truncate command
  • appendchunks β€” don't allow the client to add chunks from one file to another (mfsappendchunks)
  • snapshot β€” don't allow the client to create snapshots
  • settrash β€” don't allow the client to change trash retention time
  • setsclass β€” don't allow the client to set storage classes
  • seteattr β€” don't allow the client to set mfs extra attributes
  • setxattr β€” don't allow the client to set XATTRs
  • setfacl β€” don't allow the client to set ACLs

🌈 STORAGE CLASS GROUPS 🌈

A system admin may not want MooseFS users to be able to apply just any Storage Class to data, for security reasons. Therefore MooseFS provides a way to only allow for certain Storage Classes to be used in a mountpoint.

First, selected Storage Classes must be assigned to one of 16 (numbered from 0 to 15) Storage Class Groups. This is done when creating or modifying a Storage Class with mfsscadmin tool (see mfsscadmin(1)). Once a group is properly defined, when option sclassgroups is used in a definition of a mountpoint export, a user using this mountpoint export can only apply (set) Storage Classes from the defined group, when they use the mfssclass tool.

Example: if there are four different Storage Classes defined in a cluster, two of them assigned to group 0, two to group 1, and a mountpoint export only allows to use Storage Classes from group 1, users will only be able to set the two Storage Classes that are assigned to group 1, an attempt to set a Storage Class assigned to group 0 will result in an error and the file's class will not be changed. This does NOT affect the Storage Class inheritance rule, that is, if a user creates a new file in a directory belonging to a Storage Class in group 0, this file will belong to the same class in group 0. But if the user subsequently changes the file's Storage Class to one of the classes they are allowed to use (from group 1), they cannot change it back to its original Storage Class, as that class belongs to "forbidden" group 0.

Important! Default Storage Class group is 0, unless another is explicitly set when creating or modifying a Storage Class, so for the purpose of limiting the availability of Storage Classes for users it's better to use group numbers greater than 0. πŸ”₯

Legacy systems Up to MooseFS version 4.56.6 the mechanism of Storage Class Groups did not exist. Instead, there were two options mingoal and maxgoal, inherited from previous versions of MooseFS. If any of them were set, a user would be allowed to use only legacy Storage Classes (classes with IDs 1 to 9, named "1" to "9", with KEEP definitions 1* to 9*) with name not lower than mingoal and not higher than maxgoal plus any admin defined classes (ID>9). To simulate this behaviour, in case of an upgrade from a version that still had these classes and also used mingoal and maxgoal in config, the system will assign those legacy classes "1" to "9" to groups 1 to 9, respectively and will convert any mingoal and maxgoal to appropriate sclassgroups expression. Example: if mingoal is set to 3 and maxgoal is set to 5, sclassgroups will be set to 0,3,4,5 - 0 to allow users to use admin-defined classes, 3,4,5 to allow the use of legacy classes "3","4" and "5". The old settings should not be used, system admins should instead define Storage Class Groups of their choice and use the sclassgroups option explicitly.


πŸŽ€ EXAMPLES πŸŽ€

Real lines, real config, no edits:

*                    /       ro
192.168.1.0/24       /       rw
192.168.1.0/24       /       rw,alldirs,maproot=0,password=passcode
10.0.0.0-10.0.0.5    /test   rw,maproot=nobody,password=test
10.1.0.0/255.255.0.0 /public rw,mapall=1000:1000
10.2.0.0/16          /       rw,alldirs,maproot=0,mintrashretention=2d12h,maxtrashretention=2w
192.168.1.0/24       /       rw,disable=unlink:rmdir:truncate
192.168.1.0/24       /       rw,disable=unlink,disable=rmdir,disable=truncate

πŸ› REPORTING BUGS πŸ›

Report bugs to <bugs@moosefs.com>.

okay bestie, legal era. stay with me, it's short but it matters. ✨

  • Copyright (C) 2026 Jakub Kruszona-Zawadzki, Saglabs SA πŸ‘‘

This file is part of MooseFS. πŸ¦‹

MooseFS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2 (only). πŸ’…

not "or any later version", bestie β€” version 2 (only). literally read the fine print, it's giving very specific. 😭

MooseFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. see the GNU General Public License for more details. 🫢

okay so this is the part where it says: if it breaks, that's a you problem, no cap. it's standard free-software disclaimer energy, not a threat. πŸ™ˆ

You should have received a copy of the GNU General Public License along with this program; if not, see https://www.gnu.org/licenses/. 🌈


πŸ‘€ SEE ALSO 🌸

go read your sisters, they're iconic too:


and that's a wrap on mfsexports.cfg(5)!! πŸŽ€ this one's from MooseFS 4.59.2-1, dated May 2026 β€” go configure those exports like the main character you are, bestie. periodt. πŸ’–β­πŸ”₯

πŸ“¦ where this page comes from