Summary

Running the official amd64 SQL Server 2022 Linux image under OrbStack's Rosetta,
a RESTORE ... FROM URL (or BACKUP ... TO URL) whose S3 endpoint answers on a
plaintext (non-TLS) port terminates the sqlservr process with SIGSEGV
(exit 139). On native x86-64 the identical call returns a clean SQL error
(Msg 3201) and the server keeps running — so this is specific to the emulated
code path, not SQL Server logic.

I couldn't tell whether it's Rosetta-specific or generic emulation, because
qemu-user isn't functional in the guest (see "What I couldn't isolate"), so I'm
filing it here as the integration owner.

Environment

• OrbStack 2.2.1 (2020100), Rosetta enabled (rosetta: true)
• macOS 26.5.2 (25F84), Apple Silicon (arm64)
• Image: mcr.microsoft.com/mssql/server:2022-CU21-GDR2-ubuntu-22.04
  (sha256:46e454273ee7f971f804cfc367b2f0aeaafd258f65b77d34ac6acca85fcb8bc9),
  amd64 under Rosetta
• S3-compatible endpoint: MinIO in the same network namespace, plaintext :9000

Reproduction

docker run -d --name mssql -e ACCEPT_EULA=Y -e MSSQL_SA_PASSWORD='Test123!secure' \
  -e MSSQL_PID=Developer -e MSSQL_MEMORY_LIMIT_MB=2048 \
  mcr.microsoft.com/mssql/server:2022-CU21-GDR2-ubuntu-22.04
docker run -d --name s3 --network container:mssql \
  -e MINIO_ROOT_USER=minioadmin -e MINIO_ROOT_PASSWORD=minioadmin123 \
  minio/minio server /data --address ":9000"      # PLAINTEXT, no TLS
# wait for mssql to accept connections, then:
docker exec mssql /opt/mssql-tools18/bin/sqlcmd -C -S localhost -U sa -P 'Test123!secure' -Q "
  CREATE CREDENTIAL [s3://127.0.0.1:9000/seed] WITH IDENTITY='S3 Access Key', SECRET='minioadmin:minioadmin123';
  RESTORE FILELISTONLY FROM URL='s3://127.0.0.1:9000/seed/anything.bak';"   -- object need not exist
docker inspect mssql --format '{{.State.ExitCode}}'   # -> 139

Observed

Client: TCP Provider: Error code 0x2746 / Communication link failure (the link
fails because the server process died). docker inspect → exit=139,
OOMKilled=false. Reproduced consistently, fresh container each time.

Expected

A SQL error returned to the caller with the server still running — exactly what
happens when the endpoint speaks TLS but presents an untrusted certificate (see
below).

Emulated vs native (the discriminating evidence)

Under Rosetta the TLS path is handled cleanly (it completes a handshake and
rejects the cert); only the non-TLS path crashes. Natively every path is
clean. s3:// is always TLS, so the plaintext case is what happens when SQL
Server opens a TLS connection and receives a non-TLS response.

Why this looks like a translation-layer fault

After the crash, /var/opt/mssql/log contains no SQLDump*.txt and the
errorlog has no access-violation / dump record — it ends at normal startup.
SQL Server's structured-exception handler normally writes a stack dump on an
access violation; its absence means the process was killed before that handler
ran, which is the signature of a fault injected during translation rather than a
SQL-level fault SQL Server could trap and report.

What I couldn't isolate

I tried to reproduce under qemu-user (to distinguish Rosetta-specific from
generic emulation) by registering qemu's binfmt handler and disabling Rosetta's,
but amd64 execution then failed with exec format error — qemu-user doesn't
appear to be functional in the OrbStack guest, so I couldn't get a QEMU data
point. You're much better placed to run that comparison. If it reproduces under
Rosetta but not QEMU, it points at Rosetta core (Apple); if under both, at
something the workload does that emulators broadly mishandle.

Notes

• SQL Server on ARM/Apple Silicon is not a Microsoft-supported configuration, so
  this is a Rosetta compatibility data point rather than a supported scenario —
  filing it because a translated process segfaulting (instead of surfacing an
  error) seemed worth reporting, and the missing-dump detail may help pinpoint
  where translation goes wrong.