Created attachment 19194 [details]
Proposed fix

When running smbstatus (or other CLI tools) on platforms without POSIX robust mutex support (e.g., OpenBSD), the standard error output is polluted with multiple "mutexes requested but not available" error messages on debug level 0 (DBG_ERR).

This behavior was introduced in commit 89b16e8a0f89af2336bdaa18d39eb3eb25d5ae77 ("s3: Warn if no mutexes available at runtime").

In dbwrap_open.c and tdb_wrap.c, try_mutex defaults to true for TDB databases. When tdb_runtime_check_for_robust_mutexes() evaluates to false, Samba logs a high-priority DBG_ERR before falling back to POSIX fcntl file locking.

try_mutex is a best-effort check. Falling back to POSIX file locking when an optional OS capability is missing is expected operational flow, not an unrecoverable error (DBG_ERR). Hard mutex requirements are already explicitly handled by dbwrap_tdb_require_mutexes.

As a result, out-of-the-box installations on non-robust-mutex OSs emit error messages during normal operation.

Actual Result:
CLI tools output multiple mutexes requested but not available lines to stderr on level 0.

Expected Result:
Samba silently falls back to fcntl locking when try_mutex fails. If logging is desired, it should use DBG_INFO (level 2) or DBG_NOTICE (level 1) so standard CLI output on level 0 remains clean.

Proposed Fix:
Revert commit 89b16e8a0f89af2336bdaa18d39eb3eb25d5ae77 to restore clean silent fallback for try_mutex.