Autoseeding sometimes fails but succeeds on retry; other times it fails repeatedly with no response

[chuansao258]

The image downloaded from the official website for SQL Server 2017 CU32.

errorlog:
026-03-17 16:49:25.41 spid61s Error: 18210, Severity: 16, State: 1.
2026-03-17 16:49:25.41 spid61s BackupVirtualDeviceFile::RequestDurableMedia: Flush failure on backup device '{C70CC0DC-9573-4A37-8C97-2A2CFCA6F2E1}'. Operating system error 995(The I/O operation has been aborted because of either a thread exit or an application request.).
2026-03-17 16:49:25.42 spid61s Error: 3203, Severity: 16, State: 1.
2026-03-17 16:49:25.42 spid61s Read on "/var/opt/mssql/data/data/xxxx.mdf" failed: 87(The parameter is incorrect.)
2026-03-17 16:49:25.42 spid61s Error: 3202, Severity: 16, State: 1.
2026-03-17 16:49:25.42 spid61s Write on "{C70CC0DC-9573-4A37-8C97-2A2CFCA6F2E1}" failed: 995(The I/O operation has been aborted because of either a thread exit or an application request.)
2026-03-17 16:49:25.42 spid61s Error: 3271, Severity: 16, State: 1.
2026-03-17 16:49:25.42 spid61s A nonrecoverable I/O error occurred on file "{C70CC0DC-9573-4A37-8C97-2A2CFCA6F2E1}:" 995(The I/O operation has been aborted because of either a thread exit or an application request.).

When querying sys.dm_hadr_physical_seeding_stats, there are many failed records, and sometimes the seeding eventually succeeds. However, in some cases, the query returns empty records（remote_id,state is null） directly, and restarting the primary database resolves the issue and allows seeding to succeed again.

[tracker1]

@chuansao258 are you mounting the data directory to a Windows or MacOS Host drive path by chance? If you are, I would recommend either letting the volume exist with the running container, taking care not to re-create, but restart the same instance when working or create a named volume... for your running instance, it's pretty safe to mount a host volume for the purpose of backup/restoration, but live data against a Windows or Mac host is problematic.

note: if you are running with WSL2 integration, using a volume mounted from inside WSL2 (NOT /mnt/c/...) is safe.

The reason behind this, is windows/mac host volumes are using a virtualized file system that does synchronization to the host from the container, and it really doesn't work well under load.