Share via

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

Marcelo Marques 0 Reputation points
2026-02-23T22:49:30.06+00:00

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

SQL Server Database Engine

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Erland Sommarskog 134.7K Reputation points MVP Volunteer Moderator
    2026-06-18T14:51:38.94+00:00

    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.

    Was this answer helpful?

    0 comments
  2. David Yard 0 Reputation points
    2026-06-17T14:38:55.5933333+00:00

    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.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.