Language and Page Formatting Options
Chapter 27. File Systems
Setting the retry timeout can now prevent
autofs from starting without mounts from SSSD
When starting the
sssmap source was previously sometimes not ready to provide map information, but
sssdid not return an appropriate error to distinguish between the
map does not existand
not availablecondition. As a consequence, automounting did not work correctly, and
autofsstarted without mounts from SSSD. To fix this bug,
autofsretries asking SSSD for the master map when the
map does not existerror occurs for a configurable amount of time. Now, you can set the retry timeout to a suitable value so that the master map is read and
autofsstarts as expected. (BZ#1101782)
The autofs package now contains the
README.autofs-schema file and an updated schema
samples/autofs.schemadistribution file was out of date and incorrect. As a consequence, it is possible that somebody is using an incorrect LDAP schema. However, a change of the schema in use cannot be enforced. With this update:
README.autofs-schemafile has been added to describe the problem and recommend which schema to use, if possible.
- The schema included in the autofs package has been updated to
automount no longer needs to be restarted to access maps stored on the NIS server
autofsutility did not wait for the NIS client service when starting. As a consequence, if the network map source was not available at program start, the master map could not be read, and the
automountservice had to be restarted to access maps stored on the NIS server. With this update,
autofswaits until the master map is available to obtain a startup map. As a result,
automountcan access the map from the NIS domain, and
autofsno longer needs to be restarted on every boot.
If the NIS maps are still not available after the configured wait time, the
master_waitoption might need to be increased. In the majority of cases, the wait time used by the package is sufficient. (BZ#1383194)
Checking local mount availability with
autofs no longer leads to a lengthy timeout before failing
Previously, a server availability probe was not done for mount requests that
autofsconsidered local because a bind mount on the local machine is expected to be available for use. If the bind mount failed, an NFS mount on the local machine was then tried. However, if the NFS server was not running on the local machine, the mount attempt sometimes suffered a lengthy timeout before failing.
An availability probe has been added to the case where a bind mount is first tried, but fails, and
autofsnow falls back to trying to use an NFS server on the local machine. As a result, if a bind mount on the local machine fails, the fallback to trying an NFS mount on the local machine fails quickly if the local NFS server is not running. (BZ#1420574)
The journal is marked as idle when mounting a GFS2 file system as read-only
Previously, the kernel did not mark the file system journal as idle when mounting a GFS2 file system as read-only. As a consequence, the
gfs2_log_flush()function incorrectly tried to write a header block to the journal and a sequence-out-of-order error was logged. A patch has been applied to mark the journal idle when mounting a GFS2 file system as read-only. As a result, the mentioned error no longer occurs in the described scenario. (BZ#1213119)
id command no longer shows incorrect UIDs and GIDs
When running Red Hat Enterprise Linux on an NFSv4 client connected to an NFSv4 server, the
idcommand showed incorrect UIDs and GIDs after the key expired out of the NFS idmapper keyring. The problem persisted for 5 minutes, until the expired keys were garbage collected, after which the new key was created in the keyring and the
idcommand provided the correct output. With this update, the keyring facility has been fixed, and the
idcommand no longer shows incorrect output under the described circumstances. (BZ#1408330)
Labeled NFS is now turned off by default
The SELinux labels on a Red hat Enterprise Linux NFS server are not normally visible to NFS clients. Instead, NFS clients see all files labeled as type
nfs_tregardless of what label the files have on the server.
Since Red Hat Enterprise Linux 7.3, the NFS server has the ability to communicate individual file labels to clients. Sufficiently recent clients, such as recent Fedora clients, see NFS files labeled with the same labels that those files have on the server. This is useful in certain cases, but it can also lead to unexpected access permission problems on recent clients after a server is upgraded to Red Hat Enterprise Linux 7.3 and later.
Note that labeled NFS support is turned off by default on the NFS server. You can re-enable labeled NFS support by using the
security_labelexport option. (BZ#1406885)
autofs mounts no longer enter an infinite loop after reaching a shutdown state
autofsmount reached a shutdown state, and a mount request arrived and was processed before the mount-handling thread read the shutdown notification, the mount-handling thread previously exited without cleaning up the
autofsmount. As a consequence, the main program never reached its exit condition and entered an infinite loop, as the autofs-managed mount was left mounted. To fix this bug, the exit condition check now takes place after each request is processed, and cleanup operations are now performed if an
autofsmount has reached its shutdown state. As a result, the autofs daemon now exits as expected at shutdown. (BZ#1420584)
autofs is now more reliable when handling namespaces
autofskernel module was unable to check whether the last component of a path was a mount point in the current namespace, only whether it was a mount point in any namespace. Due to this bug,
autofssometimes incorrectly decided whether a mount point cloned into a propagation private namespace was already present.
As a consequence, the automount point failed to be mounted and the error message
Too many levels of symbolic linkswas returned. This happened, for example, when a systemd service that used the
PrivateTmpoption was restarted while an
autofsmount was active.
With this update, a namespace-aware mounted check has been added in the kernel. As a result,
autofsis now more resilient to cases where a mount namespace that includes autofs mounts has been cloned to a propagation private namespace.
For more details, see the KBase article at https://access.redhat.com/articles/3104671. (BZ#1320588)