Export rule evaluation order
Every mount starts with the Master Server checking a client's registration against the entries of mfsexports.cfg. Session and export defines both terms. The mfsexports.cfg reference lists the entry syntax with the full option list. This page covers the evaluation itself: when it runs, which entry wins when several match, and what the winner decides.
The check runs at registration, not per operation
The Master Server evaluates the entries once, when a client registers. A client registers at mount time, and again whenever the client has to register in full after its connection was closed. The values of the winning entry are copied into the client's session. Every later request from that mount is evaluated against the session. A plain reconnection after a network break does not repeat the check, so the session keeps the values that it was admitted with.
An entry matches address, version, type, path, password
An entry is a candidate for a registering client only when all of its conditions hold. The client's address must fall inside the entry's address range. The client's version must be at least the entry's minversion. The mount type must agree too: entries whose path is . are matched only by MooseFS Meta mounts, and path entries only by regular mounts. The directory that the client asks for must equal the entry's path, or be below it when the entry has alldirs. An entry for / without alldirs admits only mounts of the whole tree. An entry with a password matches only a client that proves knowledge of the password. The proof is a hash over a random challenge, which authentication between modules describes.
Among matches, the later and better entry wins
The Master Server scans the file in order and keeps one current pick. The first matching entry becomes the pick. Each later matching entry displaces the pick when the entry grants read-write and the pick is read-only. It also displaces the pick when the effective root user ID of the entry is zero and that of the pick is not. maproot=0 is the typical entry with a zero root user ID. mapall with user ID 0 on an entry that has no maproot also results in zero. So does an entry for the MooseFS Meta file system, whose path is . and which leaves root unmapped. The later entry also displaces the pick when the entry has admin and the pick does not. The same applies when the entry requires a password and the pick does not, or when the path of the entry is longer. This is not a score. An entry that is better in one respect displaces the pick even when the entry is worse in every other respect. An entry better in no respect leaves the earlier pick in place.
The outcome can therefore depend on file order. Consider a client at 192.0.2.10 that mounts /data under these entries:
192.0.2.0/24 / rw,alldirs
192.0.2.0/24 /data ro
Both match. The second entry has the longer path and therefore displaces the first entry, so the mount is read-only. With the same two entries in reverse order, the / entry comes second. That entry displaces the /data pick because it grants read-write, so the same mount is read-write.
The winning entry settles the session
The winner's values become the session's values: the access mode, the identity mapping (maproot, mapall) with the forced umask, the admin flag, and the disable mask. The Master Server refuses the operations in that mask for that session. The trash retention bounds and the Storage Class groups that the session may use come from the same entry. So do the operation rate limits, which the Master Server passes to the client to enforce. The entry's path decides which directory the client may ask for: the path itself, or anything below it when the entry has alldirs. The root of the mounted tree is the directory that the client asked for, not the entry's path. The session cannot reach anything above that root. When the / entry with alldirs wins in the example above, the mount still shows /data.
A reload re-checks every mounted client
Reloading the Master Server re-reads the file. The Master Server logs and skips a line that does not parse, and loads the rest of the file. An unknown option does not invalidate its line. The Master Server warns about the option and ignores it. The entry is added to the list with its remaining options. Only a comma separates options, so a comment appended to an entry line (192.0.2.0/24 /data rw # note) merges with the last option into a single unknown token. The rw is lost, so the entry keeps the default read-only mode. While USE_AUTH_FOR_IO is on, an entry without a password is not loaded either. The Master Server logs exports: definition without password (line: N) ignored due to using auth for I/O for each such line. Since 5.2.0, a reload that cannot use the file stops the Master Server. This happens when the file is missing or cannot be read, and when no valid entry is left. The Master Server logs a line with - exiting, followed by the error when the file cannot be opened, or no valid exports defined !!!. It then logs internal terminate request. It shuts down as it does on mfsmaster stop, writes the metadata, and exits with status 1. Up to 5.1.0, an unreadable file left the previous entries in force, and a file with no entries left the Master Server running with none. Startup fails in the same cases. The Master Server then logs init: exports manager failed !!! and error occurred during initialization - exiting. The process exits with an error instead of reaching its main loop.
Each session stores a checksum of the whole entry list as it was when the session was created. After a reload that changed the entries, the Master Server closes the connection of every registered client whose stored checksum no longer matches. The client reconnects and registers in full. The check runs against the current entries. The session record takes the values of the new winner, so a rule change applies to mounted clients without a remount. A client that no current entry admits is refused at that point. The checksum does not depend on entry order, so a reload that only reorders lines closes no connections. The new order could still produce a different winner at the next registration.
A client that matches nothing is refused
When no entry matches, the registration fails, so the mount does not happen. The client is refused with "Permission denied", with two exceptions. The status changes when at least one entry failed on the password alone. Such an entry matched the address, the version, the mount type, and the path. The status is then "Password is needed" if the client sent none, and "Incorrect password" if the client sent a wrong password. The reasons why the other entries failed do not change that status. A matching entry does not help when the requested directory does not exist in the namespace or is not a directory. Such a registration is refused too. A refused mount command fails outright, unless the client used -o mfsdelayedinit. That option moves the registration into the background, so the mount command succeeds and the client retries every 2 seconds. An already mounted client that is refused after a rule change logs the returned status and retries every 2 seconds. A corrected mfsexports.cfg therefore takes effect without restarting anything on the client side.