Red Hat SummitChapter 27. File Systems
Setting the retry timeout can now prevent autofs from starting without mounts from SSSD
When starting the
autofs utility, the sss map source was previously sometimes not ready to provide map information, but sss did not return an appropriate error to distinguish between the map does not exist and not available condition. As a consequence, automounting did not work correctly, and autofs started without mounts from SSSD. To fix this bug, autofs retries asking SSSD for the master map when the map does not exist error 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 autofs starts as expected. (BZ#1101782)
The autofs package now contains the README.autofs-schema file and an updated schema
The
samples/autofs.schema distribution 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:
- The
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
samples/autofs.schema.new. (BZ#1383910)
automount no longer needs to be restarted to access maps stored on the NIS server
Previously, the
autofs utility 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 automount service had to be restarted to access maps stored on the NIS server. With this update, autofs waits until the master map is available to obtain a startup map. As a result, automount can access the map from the NIS domain, and autofs no longer needs to be restarted on every boot.
If the NIS maps are still not available after the configured wait time, the
autofs configuration master_wait option 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
autofs considered 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
autofs now 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)
The 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
id command 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 id command provided the correct output. With this update, the keyring facility has been fixed, and the id command 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_t regardless 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_label export option. (BZ#1406885)
autofs mounts no longer enter an infinite loop after reaching a shutdown state
If an
autofs mount 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 autofs mount. 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 autofs mount 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
Previously, the
autofs kernel 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, autofs sometimes 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 links was returned. This happened, for example, when a systemd service that used the PrivateTmp option was restarted while an autofs mount was active.
With this update, a namespace-aware mounted check has been added in the kernel. As a result,
autofs is 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)
