Smb on Lessons learned

APFS sparse bundle on SMB: rsync "Operation not supported (45)" and F_FULLFSYNC

Tue, 29 Sep 2026 12:55:00 +0200

A backup job that rsyncs into encrypted disk images on a NAS started printing this for every file (paths elided):

rsync: [generator] failed to set times on …
rsync: [receiver] mkstemp …
rsync: [generator] delete_file: unlink … failed: Operation not supported (45)

Then hdiutil attach for the next image hung for over ten minutes, and the two images whose rsyncs had finished stayed mounted.

If you keep APFS sparse bundles on an SMB share and see error 45 inside them, the files aren’t the problem. The share can’t do F_FULLFSYNC, and APFS can’t commit a single transaction without it.

The setup

macOS 27.0.1 dropped AFP, so an old NAS that speaks only SMB 2.1 got mounted over SMB instead. Each backup source has its own AES-256 sparse bundle on the share, created like this:

hdiutil create -encryption AES-256 -type SPARSEBUNDLE -size 50g \
 -fs APFS -volname app -stdinpass /Volumes/backup/staging/app.sparsebundle

The job attaches a bundle, rsyncs a server’s files into it, and detaches it.

The kernel log

rsync names the files, so the obvious suspects are permissions or the files themselves. The kernel log points at the image instead (timestamps shortened, process column removed):

/usr/bin/log show --last 90m --style compact \
 --predicate 'process == "kernel" AND eventMessage CONTAINS "apfs"'

12:43:53.531 disk7s1 mount-complete volume app, requested by: mount_apfs (pid 82535); parent: mount (pid 82534)
12:43:53.532 disk7s1 Host is remote
...
12:47:45.393 (apfs) tx_flush_thread:1678: disk7 tx_flush(8311) failed, 45, # 297
12:47:45.931 (apfs) tx_flush_thread:1678: disk7 tx_flush(8311) failed, 45, # 298

APFS noticed the image lives on a remote host. From 24 seconds after mounting, it failed to flush a transaction about twice a second, with error 45 (ENOTSUP). The second mounted image did the same. Nothing written inside them was being committed.

The probe

Error 45 from a flush suggested the sync call, not the write. This script tries plain fsync and the two stronger syncs macOS offers. Run it from a directory on the share:

import fcntl, os
p = "_synctest"
fd = os.open(p, os.O_RDWR | os.O_CREAT, 0o600); os.write(fd, b"x" * 4096)
for name, op in (("fsync", None), ("F_FULLFSYNC", 51), ("F_BARRIERFSYNC", 85)):
 try:
 os.fsync(fd) if op is None else fcntl.fcntl(fd, op)
 print(name, "OK")
 except OSError as e:
 print(name, "->", e)
os.close(fd); os.unlink(p)

fsync OK
F_FULLFSYNC -> [Errno 45] Operation not supported
F_BARRIERFSYNC -> [Errno 45] Operation not supported

APFS asks the disk image to flush; the disk image passes that on as F_FULLFSYNC on its band files on the share, and the SMB client says no.

The NAS also had a share called TimeMachineBackup, and Time Machine over SMB needs full sync, so it seemed worth a try. Same result. Its Time Machine backups dated from the AFP days.

What works

Keep the image off the share. The bundles moved to a USB drive, and every healthy one attaches, writes, deletes, and detaches fine there. That’s where the job runs now.

If the image has to stay on the share, use HFS+ inside it. A test bundle on the same share, created with -fs HFS+J instead of -fs APFS, passed everything the job does: rsync with --delete-during, rename, setting times, deletes, detach and reattach.

If the server runs Samba and you control it, fruit:time machine = yes on the share makes vfs_fruit advertise the FULLSYNC volume capability to macOS clients. That should let APFS images commit, but it wasn’t tested here.

Check the images you already have

The failed commits also left damage. When the bundles were copied to the USB drive, one of them wouldn’t mount:

hdiutil: attach failed - no mountable file systems

A read-only check of its volume (fsck_apfs -n) said why:

warning: (oid 0x74e6) om: btn: invalid o_cksum (0xdfbd1ccee26c9006)
** The volume /dev/rdisk8s1 with UUID … was found to be corrupt and cannot be repaired.

Its band files had last been modified during the failed SMB run, and the original on the NAS was identical, so the copy wasn’t to blame. Since it was only a staging mirror, it got recreated empty, and the next run filled it again. After any such episode, attach each image and run diskutil verifyVolume on it.

Why restic didn’t mind

Restic repositories on the same share were unaffected. Restic is written in Go, and Go’s Fsync on macOS tries F_FULLFSYNC and falls back to plain fsync on ENOTSUP. The comment in the Go source names this exact case: “There are scenarios such as SMB mounts where fcntl will fail with ENOTSUP.” APFS inside a disk image has no such fallback: when the full flush fails, it stops committing.

Takeaway

An APFS disk image on an SMB share works only if the share supports F_FULLFSYNC. Without it, every write inside the image fails with error 45, and the failed commits can corrupt the image.

If you’re moving sparse bundles from AFP to SMB, run the probe above on the new share before you mount anything on it.

macOS SMB: OSError: [Errno 9] Bad file descriptor after a silent reconnect

Tue, 29 Sep 2026 12:15:00 +0200

A Python script that had encrypted backup archives on a NAS for months started failing on every run:

Traceback (most recent call last):
 File "/Volumes/backup/./encrypt-one.py", line 74, in <module>
 main()
 File "/Volumes/backup/./encrypt-one.py", line 38, in main
 with open(f, "rb") as src:
OSError: [Errno 9] Bad file descriptor

Then the bash script that called it stopped too. Not intermittently: start the job and something fails sooner or later.

If you run long jobs from an SMB share on macOS and get EBADF on files that are plainly there, the cause is probably a session reconnect you never saw, and the kernel log is the only place that records it.

The setup

macOS 27 dropped AFP, so an old NAS that speaks only SMB 2.1 got mounted over SMB instead. A bash script on the share runs encrypt-one.py on a few archives in parallel with xargs -P. Each run streams a 600 MB archive from the share through openssl enc and writes the result back to the same share.

The dead end

The traceback points at open(), so the first move was to open and read that archive by hand. It worked, and so did a read under xargs -P 3. A file that opens fine and a job that fails anyway tells you the file isn’t the problem. Something happens to the handle while it’s open.

The kernel log

smbutil gave the first hint:

$ smbutil statshares -m /Volumes/backup
...
SMB_VERSION SMB_2.1
SESSION_RECONNECT_TIME 2026-09-29 12:01:17
SESSION_RECONNECT_COUNT 4

Four reconnects; the last one was inside the failed run. The kernel log explains what each one does (timestamps shortened, process column removed):

/usr/bin/log show --last 1h --style compact \
 --predicate 'process == "kernel" AND eventMessage CONTAINS[c] "smb"'

11:58:15.502 (smbfs) smb_iod_sendall: id 0 ts > iod_lastrecv && ts > sr_timesent.
11:58:15.502 (smbfs) smb_iod_reconnect: id 0 Starting reconnect with nas.local
11:58:15.502 (smbfs) smb2_smb_parse_change_notify: smb_rq_reply failed 60
11:58:16.523 (smbfs) smb_iod_reconnect: id 0 The negotiate succeeded to nas.local
11:58:17.065 (smbfs) smb2fs_reconnect_dur_handle: Missing durable handle on <archive.tar.bz2.enc.tmp>
11:58:17.173 (smbfs) smb2fs_reconnect_dur_handle: Missing durable handle on <backup.sh>
11:58:17.186 (smbfs) smb2fs_reconnect_dur_handle: Missing durable handle on <archive.tar.bz2>
11:58:17.205 (smbfs) smb_iod_reconnect: id 0: Reconnect completed successfully.
11:58:17.212 (smbfs) smb2_smb_read_write_async: smb_rq_reply failed 9
11:58:17.212 (smbfs) smbfs_do_strategy: archive.tar.bz2: READ failed with an error of 9
11:58:17.283 (smbfs) smbfs_do_strategy: archive.tar.bz2.enc.tmp: WRITE failed with an error of 9

The NAS stopped answering under sustained I/O (error 60 is ETIMEDOUT). macOS dropped the session and reconnected, and that part worked. Then it tried to reattach each open file; the server had nothing to reattach them to, and every read and write on those files failed with error 9, EBADF.

Look at the middle line: backup.sh is on the list. Bash reads a script from disk as it runs, so the script file is open the whole time and goes bad with everything else. That’s why the shell stopped as well.

Why

A durable handle is how an SMB 2.x client keeps an open file across a dropped connection: the server holds the open for a while, and the client reclaims it after reconnecting. This server granted none. So “Reconnect completed successfully” is true for the session and useless for every file that was open at the time. Nothing reaches the application except EBADF on the next read or write.

What fixed it

Stop running long I/O jobs from the share. The pipeline moved to a USB drive, and only finished files go to the NAS. That ended the failures.

If you can’t move off the share, two workarounds got the job past the failing step:

Make bash read the whole script before it starts, so it never goes back to the share for the next line:
```
#!/usr/bin/env bash
{
set -euo pipefail
# ... the whole script ...
exit
}
```
Bash parses the entire { } block before running any of it, and the exit stops it from reading past the closing brace.
Make the I/O survive a reconnect: process the file in segments (64 MiB worked), open, write and fsync each segment separately, and on EBADF, EIO or EAGAIN reopen and retry only that segment. With AES-CBC you can chain the segments by using the last ciphertext block as the next IV, and the output is byte-identical to one openssl enc pass. In the test run on the share, no reconnect happened at all, probably because the per-segment fsync slowed the writes enough for the NAS to keep up.

If the server is a Samba box you control, check whether it grants durable handles: the durable handles option only takes effect with kernel oplocks = no, kernel share modes = no and posix locking = no. Turning off SMB signing on the client (signing_required=no in /etc/nsmb.conf) might also take enough load off a weak NAS CPU to prevent the stalls. Neither was tried here.

Takeaway

On macOS, an SMB reconnect to a server without durable handles invalidates every open file on the share, including a running shell script, and the only trace is Missing durable handle in the kernel log.

If you’ve seen Errno 9 on an SMB mount, run smbutil statshares -a and look at SESSION_RECONNECT_COUNT before you debug your code.