Setting the retry timeout can now prevent
autofs from starting without mounts from SSSD
When starting the
map source was previously sometimes not ready to provide map information, but
did not return an appropriate error to distinguish between the
map does not exist
condition. As a consequence, automounting did not work correctly, and
started without mounts from SSSD. To fix this bug,
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
starts as expected. (BZ#1101782
The autofs package now contains the
README.autofs-schema file and an updated schema
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:
automount no longer needs to be restarted to access maps stored on the NIS server
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
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
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)
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
export option. (BZ#1406885
autofs mounts no longer enter an infinite loop after reaching a shutdown state
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
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.