Inconsistent handling of problems with secure-file-priv parameter

Sumary

The validation of the secure_file_priv directive at server startup exhibits two major logical and logging inconsistencies:
1. When the path configured in secure_file_priv does not exist, the server aborts startup, yet the log message is incorrectly classified under the [Warning] severity label instead of [ERROR].
2. When the configured path exists but is completely inaccessible (unreadable and unwritable by the user running mariadbd), the server starts successfully without any warnings or errors. This is highly inconsistent with the strict fail-fast behavior enforced when the directory is simply missing.

Severity & Container Impact Note

This behavior is extremely disruptive in containerized, non-root, and minimal system environments (such as Docker, Podman, or Kubernetes):

• No automatic directory creation: Package managers (RPM/DEB) register directories like /var/lib/mysql-files as owned, but expect them to be dynamically created at boot time via systemd-tmpfiles. In container environments where systemd does not run, these directories are never created automatically.
• Startup Blocking by Default: Since default global configurations point secure_file_priv to /var/lib/mysql-files, any user attempting to start the server in a containerized environment (especially as a non-root user like test) will experience a silent crash (exit code 1) by default.
• High Troubleshooting Overhead: Because the server crashes before writing to the file specified in --log-error, and because the only console output is a low-severity [Warning], users must spend significant time troubleshooting why the server failed to start, eventually discovering they must manually run custom pre-startup scripts to create the directory or remember to always override/nullify secure_file_priv in their arguments.

test@3cee4cc030db:/test> /usr/sbin/mariadbd --datadir=/test/dt --user=test --socket=/test/.sock --log-error=/test/.cerr --skip-networking --disable-ssl --secure-file-priv=/var/lib/mysql-files

2026-06-05 11:20:30 0 [Warning] Failed to normalize the argument for --secure-file-priv.

test@3cee4cc030db:/test> echo $?

1

test@3cee4cc030db:/test> cat /test/.cerr

cat: /test/.cerr: No such file or directory

Proposed Fix / Expected Behavior

1. Do Not Abort Startup (Allow Server to Run): A missing or inaccessible directory specified in secure_file_priv should never prevent the server from starting.
2. Safe Fallback: If the configured directory does not exist or cannot be accessed by the running user, MariaDB should gracefully fall back to a secure state by implicitly setting secure_file_priv = NULL (disabling all import/export features).