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 addressn.n.n.n/bβ IP class specified by network address and number of significant bitsn.n.n.n/m.m.m.mβ IP class specified by network address and maskf.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 modealldirsβ 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 atmfsmasterlevel (it's still done atmfsmountlevel) β in this case "group" and "other" permissions are logically added; needed for supplementary groups to work (mfsmasterreceives 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,APPENDONLYandIMMUTABLEflags in filesystem objects
maproot=USER[:GROUP]β maps root (uid=0) accesses to given user and group (similarly tomaprootoption in NFS mounts);USERandGROUPcan be given either as name or number; if no group is specified,USER's primary group is used. Names are resolved onmfsmasterside (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 pointsclassgroups=-|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 seemfsscadmin(1); for more detailed explanation see STORAGE CLASS GROUPSpassword=PASS,md5pass=MD5β requires password authentication in order to access specified resourceminversion=VERβ rejects access from clients older than specifiedmintrashretention=TIME,maxtrashretention=TIMEβ specify range in which trash retention can be set by usersmintrashtime=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 formaxtrashretentionis 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 is65535hours (~390weeks). π
π 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 thechownoperationchmodβ don't allow the client to perform thechmodoperationsymlinkβ don't allow the client to create symbolic linksmkfifoβ don't allow the client to create FIFOsmkdevβ don't allow the client to create devicesmksockβ don't allow the client to create socketsmkdirβ don't allow the client to create directoriesunlinkβ 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) namesmoveβ don't allow the client to move inodes (files, directories) to another pathlinkβ don't allow the client to create hard linkscreateβ don't allow the client to create new filesreaddirβ don't allow the client to list directories ('ls'command will not work)readβ don't allow the client to read from fileswriteβ don't allow the client to write to filestruncateβ don't allow the client to shorten the length of a file with truncate commandsetlengthβ don't allow the client to increase the length of a file with truncate commandappendchunksβ don't allow the client to add chunks from one file to another (mfsappendchunks)snapshotβ don't allow the client to create snapshotssettrashβ don't allow the client to change trash retention timesetsclassβ don't allow the client to set storage classesseteattrβ don't allow the client to set mfs extra attributessetxattrβ don't allow the client to setXATTRssetfaclβ 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 is0, 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 than0. π₯
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>.
π COPYRIGHT π
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:
mfsmaster(8)πmfsmaster.cfg(5)β¨
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
- arch rolling: moosefs 4.59.2-2 Β· GPL-2.0-only
- nixos 26.05: moosefs 4.59.2
- nixpkgs unstable: moosefs 4.59.2
- ubuntu stonking: moosefs-master 4.59.2-1 Β· GPL-2.0-only
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms