Scroll to navigation

mfsexports.cfg(5) This is part of MooseFS mfsexports.cfg(5)

NAME

mfsexports.cfg - MooseFS access control for mfsmounts

DESCRIPTION

The file mfsexports.cfg contains MooseFS access list for mfsmount clients.

SYNTAX

Syntax is:

Lines starting with # character are ignored as comments.

ADDRESS can be specified in several forms:

*	all addresses
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 path relative to MooseFS root; special value . means MFSMETA companion filesystem.

OPTIONS list:

export tree in read-only mode; this is default
export tree in read-write mode
allows to mount any subdirectory of specified directory (similarly to NFS)
allows reconnecting of already authenticated client from any IP address (the default is to check IP address on reconnect)
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)
administrative privileges:

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

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).
like above but maps all non privileged users (uid!=0) accesses to given user and group (see notes below).
this umask is added (OR) to user's umask and the resulting umask is used in this mount point
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
requires password authentication in order to access specified resource
rejects access from clients older than specified
specify range in which trash retention can be set by users
deprectaed options (function similalry as above)
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 ommited, 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 modyfing 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

*                    /       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

Copyright (C) 2025 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).

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.

You should have received a copy of the GNU General Public License along with MooseFS; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02111-1301, USA or visit http://www.gnu.org/licenses/gpl-2.0.html

SEE ALSO

mfsmaster(8), mfsmaster.cfg(5)

February 2025 MooseFS 4.57.5-1