When using SMB to share a FUSE-mounted folder, writing from Windows 10 always results in error 0x8007045d.

[qibao07]

Describe the bug

When using SMB to share a FUSE-mounted folder, writing from Windows 10 always results in error 0x8007045d.

What is certain is that it worked fine before the upgrade, but the problem started after updating to the latest packages.

I believe the issue is more likely related to the FUSE and kernel upgrade, but I don't know how to downgrade them to pinpoint the problem.

Pre-upgrade version: Linux rpi-03 6.6.74+rpt-rpi-2712 # 1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27) aarch64

Current version: Linux rpi-03 6.12.20+rpt-rpi-2712 # 1 SMP PREEMPT Debian 1:6.12.20-1+rpt1~bpo12+1 (2025-03-19) aarch64

Start-Date: 2025-04-16  15:12:39
Commandline: apt upgrade
Requested-By: qibao (1000)
Install: linux-image-6.12.20+rpt-rpi-v8:arm64 (1:6.12.20-1+rpt1~bpo12+1, automatic), linux-image-6.12.20+rpt-rpi-2712:arm64 (1:6.12.20-1+rpt1~bpo12+1, automatic), linux-headers-6.12.20+rpt-rpi-2712:arm64 (1:6.12.20-1+rpt1~bpo12+1, automatic), linux-kbuild-6.12.20+rpt:arm64 (1:6.12.20-1+rpt1~bpo12+1, automatic), linux-headers-6.12.20+rpt-rpi-v8:arm64 (1:6.12.20-1+rpt1~bpo12+1, automatic), linux-headers-6.12.20+rpt-common-rpi:arm64 (1:6.12.20-1+rpt1~bpo12+1, automatic)
Upgrade: libperl5.36:arm64 (5.36.0-7+deb12u1, 5.36.0-7+deb12u2), containerd.io:arm64 (1.7.26-1, 1.7.27-1), firmware-nvidia-graphics:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), firmware-brcm80211:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), perl:arm64 (5.36.0-7+deb12u1, 5.36.0-7+deb12u2), liblzma5:arm64 (5.4.1-0.2, 5.4.1-1), linux-headers-rpi-v8:arm64 (1:6.6.74-1+rpt1, 1:6.12.20-1+rpt1~bpo12+1), firmware-atheros:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), libnuma1:arm64 (2.0.16-1, 2.0.18-1~rpt1), linux-headers-rpi-2712:arm64 (1:6.6.74-1+rpt1, 1:6.12.20-1+rpt1~bpo12+1), linux-image-rpi-2712:arm64 (1:6.6.74-1+rpt1, 1:6.12.20-1+rpt1~bpo12+1), xz-utils:arm64 (5.4.1-0.2, 5.4.1-1), libc6:arm64 (2.36-9+rpt2+deb12u9, 2.36-9+rpt2+deb12u10), locales:arm64 (2.36-9+rpt2+deb12u9, 2.36-9+rpt2+deb12u10), firmware-mediatek:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), firmware-realtek:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), network-manager:arm64 (1.42.4-1+rpt1, 1.42.4-1+rpt1+deb12u1), firmware-libertas:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), raspi-firmware:arm64 (1:1.20250305-1, 1:1.20250326-1), firmware-marvell-prestera:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), firmware-misc-nonfree:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), linux-image-rpi-v8:arm64 (1:6.6.74-1+rpt1, 1:6.12.20-1+rpt1~bpo12+1), libc-dev-bin:arm64 (2.36-9+rpt2+deb12u9, 2.36-9+rpt2+deb12u10), perl-base:arm64 (5.36.0-7+deb12u1, 5.36.0-7+deb12u2), libc-l10n:arm64 (2.36-9+rpt2+deb12u9, 2.36-9+rpt2+deb12u10), libc-bin:arm64 (2.36-9+rpt2+deb12u9, 2.36-9+rpt2+deb12u10), libc-devtools:arm64 (2.36-9+rpt2+deb12u9, 2.36-9+rpt2+deb12u10), libc6-dbg:arm64 (2.36-9+rpt2+deb12u9, 2.36-9+rpt2+deb12u10), libc6-dev:arm64 (2.36-9+rpt2+deb12u9, 2.36-9+rpt2+deb12u10), perl-modules-5.36:arm64 (5.36.0-7+deb12u1, 5.36.0-7+deb12u2), libnm0:arm64 (1.42.4-1+rpt1, 1.42.4-1+rpt1+deb12u1), raspberrypi-sys-mods:arm64 (20241202, 20250414), firmware-intel-misc:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), firmware-intel-graphics:arm64 (1:20240709-2~bpo12+1+rpt2, 1:20240709-2~bpo12+1+rpt3), linux-libc-dev:arm64 (1:6.6.74-1+rpt1, 1:6.12.20-1+rpt1~bpo12+1)
End-Date: 2025-04-16  15:14:22

Steps to reproduce the behaviour

1. Mount a directory using FUSE.

docker run -d \
  --name clouddrive \
  --restart unless-stopped \
  --env CLOUDDRIVE_HOME=/Config \
  -v $HOME/DockerData/clouddrive/CloudNAS:/CloudNAS:shared \
  -v $HOME/DockerData/clouddrive/Config:/Config \
  -v /home/qibao/MyDisk:/MyDisk \
  -p 19798:19798 \
  --pid host \
  --privileged \
  --device /dev/fuse:/dev/fuse \
  cloudnas/clouddrive2-unstable:0.8.16-beta5

2. Start the Samba service.

docker run -d --name samba --net host --restart unless-stopped \
  -e TZ=Asia/Shanghai \
  -e USERID=$(id -u) \
  -e GROUPID=$(id -g) \
  -v $HOME/DockerData:/DockerData:rshared \
  quay.io/unixfox/samba:build-20241014 -p \
  -W -n -S -r \
  -g "vfs objects = catia" \
  -g "log level = 5" \
  -g "log file = /DockerData/samba/smb.log" \
  -s "tmp;/DockerData/clouddrive/CloudNAS/CloudDrive;yes;no;yes"

3. At this point, when accessing the file share from Windows 10 or Windows 11 and trying to create a new file, an error 0x8007045d is shown, although the file is actually created successfully.

Samba logs at this moment:

vfs_ChDir to /DockerData/clouddrive/CloudNAS/CloudDrive
vfs_ChDir: vfs_ChDir got /DockerData/clouddrive/CloudNAS/CloudDrive
print_impersonation_info: Impersonated user: uid=(1000,1000), gid=(0,1000), cwd=[/DockerData/clouddrive/CloudNAS/CloudDrive]
fsp_new: allocated files structure (1 used)
fsp_new: allocated files structure (2 used)
file_free: freed files structure 0 (1 used)
fsp_new: allocated files structure (2 used)
file_new: new file fnum [invalid value]
file_free: freed files structure 0 (1 used)
fsp_new: allocated files structure (2 used)
dbwrap_lock_order_lock: check lock order 1 for /var/cache/samba/smbXsrv_open_global.tdb
dbwrap_lock_order_unlock: release lock order 1 for /var/cache/samba/smbXsrv_open_global.tdb
file_new: new file fnum 804500124

Device (s)

Raspberry Pi 5

System

Raspberry Pi reference 2024-11-19
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 891df1e21ed2b6099a2e6a13e26c91dea44b34d4, stage2

2025/03/10 17:10:37
Copyright (c) 2012 Broadcom
version 2bb2ae64 (release) (embedded)

Linux rpi-03 6.12.20+rpt-rpi-2712 # 1 SMP PREEMPT Debian 1:6.12.20-1+rpt1~bpo12+1 (2025-03-19) aarch64 GNU/Linux

Logs

No response

Additional context

No response

[pelwell]

I think it's unlikely that this issue is Pi-specific, and we are not going to have the time to look into such a niche problem.

Does the SMB log extract above cover 1 or 2 file creations? The message file_new: new file fnum [invalid value] is interesting - you could try to see what triggers it. You could also help diagnose the problem by splitting the problem space - try sharing a regular, non-FUSE directory using SAMBA. Whether that succeeds or fails may point to where the problem lies, and if it succeeds you could verify that it is necessary to use a FUSE filing system.

[qibao07]

@pelwell

Non-FUSE work fine, and that's how I'm handling it for now.

But it was working fine before the upgrade — the issue only started after updating to the latest packages.

I have two Raspberry Pi 5Bs. Everything was working normally before. After the issue appeared, I tried running the same service on the other Raspberry Pi 5B, and it worked fine. But once I ran apt upgrade on it as well, the same issue occurred.

And it seems the problem can be almost certainly narrowed down to the packages mentioned above.

[pelwell]

You can rewind to older kernels using rpi-update. This page (https://github.com/raspberrypi/rpi-firmware/commits/master/) lists all of the releases we have made, and you can select any one using the hexadecimal values (shortened git hashes) on the right hand side of the page. For example, to go back to the last 6.6 release you would run:

$ sudo rpi-update b5e0052

I advise you to back up any important data first, just in case.

Another good one to try would be the release after that, which was the first from the 6.12 kernel:

$ sudo rpi-update fcb540e

If the former works and the latter doesn't (which is my prediction) then are a lot of kernel versions (6.7-6.11) to comb through looking for the problem.

[qibao07]

The hypothesis matches the result exactly — version 6.6 works fine, while the issue occurs in version 6.12.

[pelwell]

That's what I was afraid of. I'll see about getting you some intermediate kernel builds to try.

[qibao07]

Hello, any updates? I'm more than happy to assist with testing on my side.