** Description changed:
[ Impact ]
- * An explanation of the effects of the bug on users and justification
- for backporting the fix to the stable release.
-
- * In addition, it is helpful, but not required, to include an
- explanation of how the upload fixes this bug.
+ When deleting files from a fuse mergerfs filesystem, there is a
+ particular scenario where the samba process will panic and crash (see
+ original description for one such case).
+
+ The fix is available from upstream and is being brought to this SRU,
+ which affects noble only. A client-side reproducer was created with the
+ assistance of AI and it reliably reproduces the server-side crash. With
+ the patches applied, the crash is gone.
+
[ Test Plan ]
- * detailed instructions how to reproduce the bug
-
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package
- fixes the problem.
-
- * if other testing is appropriate to perform before landing this
- update, this should also be described here.
+ There are two scripts attached to this bug:
+
+ repro-in-lxc.sh
+ smb2_close_fullinfo_delete.py
+
+ These scripts expect that LXD is configured on the host, and that lxc
+ commands can be run by the user executing that script.
+
+ Download them to a directory of your choice.
+
+ To reproduce the bug, run:
+
+ $ ./repro-in-lxc.sh noble n-panic
+
+ This will create a noble LXD container, named n-panic, setup samba and
+ the mergerfs mountpoint, copy the python script to it, and perform the
+ delete operation that is known to reproduce the crash.
+
+ To validate the fix, run:
+
+ $ ./repro-in-lxc.sh noble n-panic --pocket proposed
+
+ That will perform the same steps, but with samba from proposed. The
+ crash must not occur.
+
+ The script detects if the crash occurred or not, and shows which version
+ of samba was used.
+
+ Here is a sample output reproducing the bug (with some text removed for
+ brevity):
+
+ $ ./repro-in-lxc.sh noble n
+ Launching n
+ Installing base packages
+ Scanning processes...
+ Scanning candidates...
+ Creating Samba user
+ Mounting mergerfs
+ Configuring Samba share
+ Restarting smbd
+ Setting up venv and installing smbprotocol
+
+ === Running reproducer ===
+
+ Reproducer failed with traceback (expected for crash).
+
+ Traceback (most recent call last):
+ File "/home/ubuntu/smb2_close_fullinfo_delete.py", line 57, in <module>
+ main()
+ (...)
+ smbprotocol.exceptions.SMBConnectionClosed: SMB socket was closed, cannot
send or receive any more data
+
+ === Samba PANIC ===
+
+ PANIC: assert failed at source3/smbd/fd_handle.c(39): (fh->fd == -1) ||
(fh->fd == AT_FDCWD)
+ [2026/09/23 16:48:40.269937, 0] lib/util/fault.c:178(smb_panic_log)
+ (...)
+ [2026/09/23 16:48:40.271933, 0] source3/lib/dumpcore.c:317(dump_core)
+ coredump is handled by helper binary specified at
/proc/sys/kernel/core_pattern
+
+ Reproducer: bug reproduced.
+
+ === Samba package origin ===
+
+ samba:
+ Installed: 2:4.19.5+dfsg-4ubuntu9.7
+ Candidate: 2:4.19.5+dfsg-4ubuntu9.7
+ Version table:
+ *** 2:4.19.5+dfsg-4ubuntu9.7 500
+ 500 http://br.archive.ubuntu.com/ubuntu noble-updates/main amd64
Packages
+ 500 http://br.archive.ubuntu.com/ubuntu noble-security/main amd64
Packages
+ 100 /var/lib/dpkg/status
+ 2:4.19.5+dfsg-4ubuntu9 500
+ 500 http://br.archive.ubuntu.com/ubuntu noble/main amd64 Packages
+
+
+ And here is the output when the crash didn't happen (I used a PPA for
+ the example: real test plan verification must be done with the proposed
+ pocket):
+
+ $ ./repro-in-lxc.sh noble n --pocket ppa:ahasenack/samba-panic
+ Launching n
+ Adding PPA ppa:ahasenack/samba-panic
+ Installing packages from noble-proposed
+ Scanning processes...
+ Scanning candidates...
+ Creating Samba user
+ Mounting mergerfs
+ Configuring Samba share
+ Restarting smbd
+ Setting up venv and installing smbprotocol
+
+ === Running reproducer ===
+
+
+ === Samba PANIC ===
+
+
+ Reproducer: PANIC not found, assuming bug is fixed.
+
+ === Samba package origin ===
+
+ samba:
+ Installed: 2:4.19.5+dfsg-4ubuntu9.8~ppa1
+ Candidate: 2:4.19.5+dfsg-4ubuntu9.8~ppa1
+ Version table:
+ *** 2:4.19.5+dfsg-4ubuntu9.8~ppa1 500
+ 500 https://ppa.launchpadcontent.net/ahasenack/samba-panic/ubuntu
noble/main amd64 Packages
+ 100 /var/lib/dpkg/status
+ 2:4.19.5+dfsg-4ubuntu9.7 500
+ 500 http://br.archive.ubuntu.com/ubuntu noble-updates/main amd64
Packages
+ 500 http://br.archive.ubuntu.com/ubuntu noble-security/main amd64
Packages
+ 2:4.19.5+dfsg-4ubuntu9 500
+ 500 http://br.archive.ubuntu.com/ubuntu noble/main amd64 Packages
+
+
[ Where problems could occur ]
- * Think about what the upload changes in the software. Imagine the
- change is wrong or breaks something else: how would this show up?
-
- * It is assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the event
- of a regression.
-
- * This must never be "None" or "Low", or entirely an argument as to why
- your upload is low risk.
-
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the SRU.
+ The patches are around samba file operations, which are obviously a
+ critical path. If a regression happens, it should be immediately obvious
+ (as file serving is the central part of samba). The package has a suite
+ of autopkgtests covering many aspects of samba, but the file operations
+ it does are simple, and definitely not using any FUSE filesystem. We
+ have tests for domain integration, domain serving, authenticated and
+ anonymous file share, cifs, with and without uring.
[ Other Info ]
- * Anything else you think is useful to include
-
- * Make sure to explain any deviation from the norm, to save the SRU
- reviewer from having to infer your reasoning, possibly incorrectly.
- This should also help reduce review iterations, particularly when the
- reason for the deviation is not obvious.
-
- * Anticipate questions from users, SRU, +1 maintenance, security teams
- and the Technical Board and address these questions in advance
+ N/A
[ Original Description ]
**Package:** samba
**Ubuntu:** 24.04.4 LTS (Noble)
**Architecture:** amd64
**Installed version:** `2:4.19.5+dfsg-4ubuntu9.7`
### Problem
Samba in Ubuntu 24.04.4 LTS still uses Samba 4.19.5, reproduces upstream
SAMBA Bug 15527 (https://bugzilla.samba.org/show_bug.cgi?id=15527) when
an SMB share is backed by a mergerfs/FUSE filesystem.
I have a share at `/mnt/data`, which is:
```
/mnt/data mergerfs fuse.mergerfs rw,...,allow_other
```
A SKYBOX VR client connects over SMB and can browse and play files
normally. When it attempts to delete a file:
1. The file is actually deleted from the filesystem.
2. Samba returns `NT_STATUS_ACCESS_DENIED` during SMB2 CLOSE.
3. `smbd` then hits the `fd_handle_destructor()` assertion and panics.
4. SKYBOX reports "Failed to delete", although the file has already
disappeared.
The relevant stock Samba 4.19.5 log was:
```
ratcliffes opened file media/TV Shows/The Wonder Years/aaa.jpg read=No
write=No
ratcliffes closed file media/TV Shows/The Wonder Years/aaa.jpg (numopen=0)
NT_STATUS_ACCESS_DENIED
PANIC: assert failed at source3/smbd/fd_handle.c
(fh->fd == -1) || (fh->fd == AT_FDCWD)
```
This corresponds directly to upstream SAMBA Bug 15527, which is
documented as:
```
fd_handle_destructor() panics within an smbd_smb2_close()
if vfs_stat_fsp() fails in fd_close()
```
The bug was fixed upstream in Samba 4.19.6.
### Verification
I built Ubuntu's existing 4.19.5+dfsg-4ubuntu9.7 source package with the
upstream SAMBA Bug 15527 fix applied, retaining Ubuntu's existing patch
stack.
The fix consists of the two upstream changes to `close.c` and `open.c`,
including resetting:
```
fsp->fsp_flags.fstat_before_close = false;
```
and ensuring the file descriptor is closed even when `vfs_stat_fsp()`
fails.
I installed the resulting packages and repeated the exact same SKYBOX
deletion test.
**Result:** the file was deleted successfully and SKYBOX reported
successful deletion. There was no `fd_handle_destructor` assertion or
smbd panic.
### Request
Please consider backporting the upstream Samba 4.19.6 Bug 15527 fix
into the Ubuntu 24.04.4 LTS Samba package.
This appears particularly relevant to users using Samba shares backed by
FUSE filesystems such as mergerfs... especially because this is a
prominent bug in an LTS release.
Upstream Samba 4.19.6 release notes identify SAMBA Bug 15527 as fixed:
https://www.samba.org/samba/history/samba-4.19.6.html
The current Noble package remains 4.19.5:
`2:4.19.5+dfsg-4ubuntu9.7`
** Also affects: samba (Ubuntu Noble)
Importance: Undecided
Status: New
** Changed in: samba (Ubuntu Noble)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: samba (Ubuntu Noble)
Status: New => In Progress
** Changed in: samba (Ubuntu)
Status: Triaged => Fix Released
** Attachment added: "repro-in-lxc.sh"
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2166678/+attachment/6002027/+files/repro-in-lxc.sh
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166678
Title:
Samba 4.19.5 in Ubuntu 24.04.4 LTS hits upstream Bug 15527 with
mergerfs/FUSE, causing SMB2 CLOSE failure and smbd panic
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2166678/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
