RedHat Linux 9.7 SQL Server 2025 CU2 Fails to write database backup to Linux NFS Share

Marcelo Marques 0 Reputation points

Hello,

I have a VMWare VM running RedHat Linux 9.7 and SQL Server 2022 CU 23.

SQL Server 2022 can successfully write database backups and the mssql agent job text log file to the Linux NFS share.

I successfully upgraded the VM to SQL Server 2025 CU2.

However, SQL Server 2025 CU 2 fails to write database backups to the Linux NFS Share.

Operating system error 5 (Access is denied.).

But the mssql agent job text log file is created on the Linux NFS Share.

BACKUP LOG agmgdbsql2
TO DISK = '/mnt/nfs/pssoldbunix/db_bkp_active_yes/mondblnxsql1/mssql_default/agmgdbsql22/agmgdbsql22_backup_2026_02_20_131756.trn' 
WITH RETAINDAYS = 8, NOFORMAT, NOINIT,
NAME = 'agmgdbsql22_backup_2026_02_20_131756.trn',
SKIP, COMPRESSION,
ENCRYPTION(ALGORITHM = AES_256, SERVER CERTIFICATE = [mondblnxsql1_cert]), STATS = 10
GO

Msg 3201, Level 16, State 1, Line 1
Cannot open backup device '/mnt/nfs/pssoldbunix/db_bkp_active_yes/mondblnxsql1/mssql_default/agmgdbsql22/agmgdbsql22_backup_2026_02_20_131756.trn'. 
Operating system error 5(Access is denied.).
Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.

Note, the same works fine with SQL Server 2022 CU 23.

The SELINUX is set to permissive. I disabled it, rebooted the machine, but SQL Server 2025 still fails to write the backup to the Linux NFS Share.

I also tried these other two workarounds, but they did not resolve the problem.

WORKAROUND 1 - remount the linux nfs share

$ ps -eZ | grep -E 'sqlservr|sqlpal'
system_u:system_r:mssql_server_t:s0 17252 ? 00:00:00 sqlservr
system_u:system_r:mssql_server_t:s0 17266 ? 00:00:22 sqlservr

# umount /mnt/nfs/pssoldbunix

# df -kh

--recommended mssql_db_t per mssql2025 documentation

# mount -t nfs4 \
-o rw,context="system_u:object_r:mssql_db_t:s0" \
lasstrsvm18p03:/pssoldbunix \
/mnt/nfs/pssoldbunix

# df -kh

# ls -Zd /mnt/nfs/pssoldbunix
system_u:object_r:mssql_db_t:s0
systemctl restart mssql-server

# cat /etc/fstab
lasstrsvm18p03:/pssoldbunix /mnt/nfs/pssoldbunix nfs4 rw,context=system_u:object_r:mssql_db_t:s0 0 0

WORKAROUND 2: custom SELinux policy

# look for denies
# sudo ausearch -m avc -ts recent | tail -n 50

/*
----
time->Fri Feb 20 13:33:28 2026
type=PROCTITLE msg=audit(1771623208.141:1523): proctitle="/opt/mssql/bin/sqlservr"
type=SYSCALL msg=audit(1771623208.141:1523): arch=c000003e syscall=87 success=yes exit=0 a0=7f2eeda39000 a1=7f2eeda2c400 a2=7f2eedffd590 a3=80 items=0 ppid=14468 pid=14472 auid=4294967295 uid=980 gid=980 euid=980 suid=980 fsuid=980 egid=980 sgid=980 fsgid=980 tty=(none) ses=4294967295 comm="sqlservr.exe_" exe="/opt/mssql/bin/sqlservr" subj=system_u:system_r:mssql_server_t:s0 key=(null)
type=AVC msg=audit(1771623208.141:1523): avc: denied { unlink } for pid=14472 comm="sqlservr.exe_" name=".agmgdbsql22_backup_2026_02_20_131756.trn.QDHZel" dev="0:52" ino=9271140469847365033 scontext=system_u:system_r:mssql_server_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=file permissive=1
type=AVC msg=audit(1771623208.141:1523): avc: denied { remove_name } for pid=14472 comm="sqlservr.exe_" name=".agmgdbsql22_backup_2026_02_20_131756.trn.QDHZel" dev="0:52" ino=9271140469847365033 scontext=system_u:system_r:mssql_server_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir permissive=1
----
*/

# ausearch -m avc -c sqlservr

# ausearch -m avc -c sqlservr | audit2allow -M mssql_nfs

# semodule -i mssql_nfs.pp

# sudo semodule -l | grep -i mssql_nfs

# reboot

I used a VMWare VM snapshot to revert back to SQL Server 2022 CU 23, and it works fine to write the database backups and the mssql agent job text log file to the Linux NFS Share.
Questions:

a. Is there a security update in SQL Server 2025 CU 2 that could be causing the issue?

b. If yes, how can I fix the problem so SQL Server 2025 can successfully write the backup to the Linux NFS Share?

c. If not, could this be a bug in SQL Server 2025 CU2?

We cannot upgrade to SQL Server 2025 CU 2 until we resolve this problem.

I appreciate any assistance you can offer.

Thanks,
Marcelo Marques
Senior Principal Product Engineer
Esri Professional Services ArcGIS Products Team

  1. Lakshmi Narayana Garikapati 1,330 Reputation points • Microsoft External Staff • Moderator

    Hi Marcelo Marques,

    Thank you for reaching out to the SQL Forum.

    To help resolve this further, I recommend raising a support ticket so our support team can assist you directly. Please refer to the following link for instructions on how to create a support ticket:

    https://support.serviceshub.microsoft.com/supportforbusiness/create

    We appreciate your engagement and thank you for being an active part of the community.

    Thanks,

    Lakshmi.

Sign in to comment

2 answers

  1. Erland Sommarskog 134.7K Reputation points • MVP • Volunteer Moderator

    Cumulative Update 6 for SQL 2025 came out today. I noticed that there were several fixes specific for SQL Server on Linux, at least of one was related to Backup. I don't know if any of the fixes are related to the problem Marcelo ran into, but it could be worth testing.

    0 comments No comments
    Sign in to comment
  2. David Yard 0 Reputation points

    This looks like a behavior change in how SQL Server 2025 handles file operations on NFS mounts compared to 2022. The audit log is the key clue — even in permissive mode, the AVC denials show mssql_server_t trying to unlink and remove_name on a file labeled nfs_t, not mssql_db_t. That means the mount context isn't being applied to the temp file SQL Server creates before renaming it to the final backup file.

    SQL Server 2025 likely changed its backup write pattern — it now writes to a hidden temp file first (notice the .QDHZel suffix) and then renames/unlinks it atomically. That temp file is getting the nfs_t label from the NFS layer rather than inheriting mssql_db_t from the mount context, which breaks the operation.

    Things to try:

    1. Your audit2allow custom policy in Workaround 2 was on the right track but may not have included all the required permissions. Regenerate it after capturing a full set of denials with ausearch -m avc -ts recent immediately after a failed backup attempt, then rebuild and reload the policy module.
    2. Add the nosharecache NFS mount option. Some NFS client caching behavior bypasses the mount context label on newly created files.
    3. Check whether SQL Server 2025 introduced a new mssql_backup_t SELinux type in its shipped policy. Run seinfo -t | grep mssql and compare what 2022 vs 2025 installed. If 2025 added new types, NFS context mapping may need to reference those instead.

    To answer your questions directly: this is almost certainly a behavior change in SQL Server 2025's backup write pattern combined with how SELinux labels NFS-created temp files — not a straightforward permission bug. It warrants a Microsoft support case with the full audit log attached, since they need to confirm whether this is intentional hardening or a regression.

    0 comments No comments
    Sign in to comment
Sign in to answer

Your answer