Bug 16066 - vfs_fruit: fruit_get_bandsize sends H-lease break to active Time Machine session, reliably killing large backups
Summary: vfs_fruit: fruit_get_bandsize sends H-lease break to active Time Machine sess...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 4.23.3
Hardware: x64 Linux
: P5 major (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-05-03 19:33 UTC by pzima
Modified: 2026-05-03 19:33 UTC (History)
0 users

See Also:


Attachments
Patch for source3/modules/vfs_fruit.c — fruit_get_bandsize: replace VFS I/O with POSIX to avoid SMB2 H-lease break (git apply or patch -p1 < vfs_fruit_posix_io.patch) (2.86 KB, patch)
2026-05-03 19:33 UTC, pzima
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description pzima 2026-05-03 19:33:15 UTC
Created attachment 18958 [details]
Patch for source3/modules/vfs_fruit.c — fruit_get_bandsize: replace VFS I/O with POSIX to avoid SMB2 H-lease break (git apply or patch -p1 < vfs_fruit_posix_io.patch)

I've been chasing TM backup failures (Proxmox, U-Green DXP NAS, ZFS), where large initial backups died every time with this in the log:

lease break timed out for file MBPP.sparsebundle/Info.plist

Tracked it down to fruit_get_bandsize opening Info.plist via SMB_VFS_NEXT_CREATE_FILE with INTERNAL_OPEN_ONLY.
Despite the flag name, this still fires an H-lease break at the active TM session. When TM is busy writing bands it doesn't respond in time and the backup dies.
At first I thought that ZFS breaks it, but in my opinion, with ZFS the write latency just makes it worse - how ever, the race, I assume, is in Samba, and not the filesystem.

Fix: plist is already an absolute path at that point, no reason to go through VFS at all. Replacing the whole LSTAT + CREATE_FILE + PREAD + close_file_free block with stat/open/pread/close bypasses the lease machinery entirely.
                                                                                                                                                                
Patch attached.

Running since April on 4.23.1, rebuilt against 4.23.3 last week, no timeouts since. Before the patch I couldn't finish a single large backup.

Probably affects 4.24.x too.