Hi everyone,

I've recently uncovered a sort of bug with samba, where whenever I do a share-to-share copy with my Windows 10 client PC from a non-BTRFS drive to a BTRFS drive, samba crashes and the transfer is interrupted. I wanted to log a ticket on the samba bugzilla, but they said I should upgrade samba first, since 4.13 is quite old... I can see that Backports contain samba 4.17.12, but I can't install it:

# apt install samba/bullseye-backports
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '2:4.17.12+dfsg-0+deb12u1~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'samba'
Selected version '2:4.17.12+dfsg-0+deb12u1~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'python3-samba' because of 'samba'
Selected version '2:4.17.12+dfsg-0+deb12u1~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'samba-libs' because of 'python3-samba'
Selected version '2:2.6.2+samba4.17.12+dfsg-0+deb12u1~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'libldb2' because of 'samba-libs'
Selected version '2.3.4-2~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'libtalloc2' because of 'libldb2'
Selected version '1.4.7-2~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'libtdb1' because of 'libldb2'
Selected version '0.13.0-2~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'libtevent0' because of 'libldb2'
Selected version '2.3.4-2~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'python3-talloc' because of 'python3-samba'
Selected version '2:4.17.12+dfsg-0+deb12u1~bpo11+1' (Debian Backports:bullseye-backports [all]) for 'samba-common' because of 'samba'
Selected version '2:4.17.12+dfsg-0+deb12u1~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'samba-common-bin' because of 'samba'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 samba : Depends: libldb2 (>= 2:2.6.1) but 2:2.2.3-2~deb11u2 is to be installed
         Depends: libtdb1 (>= 1.4.7~) but 1.4.3-1+b1 is to be installed
 samba-common-bin : Depends: libtdb1 (>= 1.4.7~) but 1.4.3-1+b1 is to be installed
                    Depends: libwbclient0 (>= 2:4.0.3+dfsg1) but it is not installable
 samba-libs : Depends: libldb2 (>= 2:2.6.2) but 2:2.2.3-2~deb11u2 is to be installed
              Depends: libtdb1 (>= 1.4.7~) but 1.4.3-1+b1 is to be installed
              Depends: libwbclient0 (>= 2:4.5.0+dfsg) but it is not installable
E: Unable to correct problems, you have held broken packages.

In my infinite wisdom, I tried `apt remove samba` and then installing the backport version of samba; that worked, but it also uninstalled openmediavault.

Luckily reinstalling was fairly straightforward but it's a bit of a hassle that apparently omv is strongly dependent on samba and a lot of its dependencies...

How would I best proceed to upgrade samba to the backports version without uninstalling openmediavault?

I see.

Since this is my productive NAS I'll need to give it some thought...

Where could I best track what works and what doesn't yet for OMV 7.x?

RIght now I would definitely need access to:

• openZFS Plugin
• onedrive Plugin
• omv-compose Plugin
• samba
• ftp plugin

If these plugins/features work, I guess I could take the plunge and jump onto the betawagon.

Hi Krisbee,

yes that is exactly the issue I am running into! I will test it on a more up to date samba in VM and report it upstream with samba after all. For now, the workaround posted in the link you provided would also be a good option for me (disable "shadow_copy2")... Perhaps just "shadow_copy" would work without errors... Will test this in the near future and report here/in the linked thread.

Hi, just a quick update: Removing just "shadow_copy2" or replacing it with "shadow_copy" does not work.

The last statement here (The smb segfault only happens with shadow_copy2 enabled, which won't be enabled in anything other than btrfs.) led me to think that the shadow_copy function is actually the issue, but it seems to be caused by the "btrfs" vfs object.

Removing just the "btrfs" from the vfs objects parameter resolves the issue when copying from a non-btrfs filesystem to a btrfs filesystem.

This makes sense to me, as it seems the filesystem tries to use a cp --reflink sort of copy function and that might error out when it attempts it on a non-btrfs source. Not quite sure though. (https://www.samba.org/samba/do…man-html/vfs_btrfs.8.html)

Hearing that 4.17 still seems to have this issue, I'll have to evaluate via VM if this issue is indeed solved in newer versions of Samba, otherwise I'll log a bug with Samba upstream and report back here. @Krissbee Could you provide the segfault from log of Samba and the exact version after all, if I manage to reproduce it on a more recent version (i.e. Samba 4.19)? That would give me more leverage to demonstrate to the maintainers, that the bug indeed still manifests in more recent Samba versions.

Krisbee Thanks again for the help! I logged the issue here: https://bugzilla.samba.org/show_bug.cgi?id=15539

That's interesting indeed, because I recreated the issue in a virtual machine, too.

On my PROD server I'm using a Mellanox ConnectX3 10Gbit NIC on the server side and on the client side it is either another ConnectX3, a realtekt 1gbit or 2.5gbit or an Intel AC9620 Wifi NIC. I really don't think it has anything to do with the NIC.

Can you check your smb.conf? Does it have the `vfs objects = btrfs` set for the BTRFS shares?

Edit: Reading your post again, I'm not sure you are actually doing what is needed to replicate this. Copying to and from the btrfs drives works fine in general. What does not work is copying between a non-btrfs drive and a btrfs drive via the smb client machine (windows). I.e. using Windows explorer, copy directly from your EXT4-Share to the BTRFS-Share and you should run into the same issue. Pretty sure this is a general samba issue at this point.