Raspberry Pi 3B+ losing connection to mounted samba share and crashing

Troubleshooting
1

Creating a bug report/issue

I have searched the existing open and closed issues

I have a RPi400 and an RPi3B+, both running the latest (updated) DietPi. Both were running on SD cards, but I switched the RPi3B+ to run from an SSD after thinking these issues were caused by a corrupted SD card but the issues continue so here I am.

The RPi400 has an external btrfs drive shared via samba, drive permissions are 777 and the samba share includes 0777 masks so permissions should not be an issue (and historically haven’t been). The RPi3B+ shares the SSD in a similar way, but now only a specific folder and not the whole drive as it’s now the boot drive, the RPi400 has no problems with this share being mounted.

For some reason I think the RPi3B+ is losing connection to the RPi400’s samba share, which causes all sorts of errors and makes the RPi3B+ crash. I then have to pull the plug, it reboots fine but quickly crashes again. It has Docker containers that rely on the mounted drive, and I assume it crashes as soon as the containers try to use the mounted drive.

Here’s a pic of the errors, I can’t access any logs due to the errors. :frowning:

image
image1487×1487 538 KB

NB: 192.168.1.243 is the RPi400.

2

Both pis are connected via wifi.

Gemini suggested disabling caching in the fstab mount and turning off the wifi power saving mode. I’ve tried these now (had to rebuild everything in order to do so) and will see how it goes, but posted for others to see and in case someone can debug without access to logs.

3 
CIFS: VFS: \\192.168.1.243 has not responded in 180 seconds
task kworker/... blocked for more than ... seconds
repeated close cached dir rc -11

So the CIFS share does not respond, it’s not available for some reason. I guess you already checked on the Pi400 and the CIFS server is active?!
Can you share your fstab please.

AI suggested this can be caused by unstable wifi, are you able to test it with a wired connection?

The hanging comes indeed from docker. Containers repeatedly touching the dead SMB mount can spam kernel workers, can deadlock processes and make shutdown/reboot impossible without pulling power.

4

Maybe it has todo with the new buggy 6.18 kernel? Looks like there are lot of problems with this kernel (see my camera thread).

5

I don’t see you problem as a bug, you’re using the legacy camera stack, which is deprecated for years, it’s not maintained anymore so sooner or later you will run into problems.

And there are no other reports about 6.18 and problems with CIFS shares, so I don’t think this is general but with the kernel.

6

There are a lot of reports about kernel 6.18. Read my thread. Some report lan problems, some report crash under heavy load or that it is no longer possible to load dtoverlays.
And in this case here it can be wifi problems. Maybe downgrading to kernel 6.12 can help. Or let’s just say it’s worth a try.

7

Yes, the RPi400 and samba share are still active, I can access them fine. Which is strange because it implies the RPi3B thinks the RPi400 isn’t responding when it actually is. Here’s my fstab from before disabling caching:

//192.168.1.243/RPi400EHD /mnt/RPi400EHD cifs cred=/var/lib/dietpi/dietpi-drive_manager/mnt-RPi400EHD.cred,iocharset=utf8,gid=dietpi,file_mode=0770,dir_mode=0770,vers=3.1.1,noauto,x-systemd.automount

Disabling caching in the fstab mount and turning off the wifi power saving mode helped a little, I was able to do a few things (which included accessing the mount) but it did crash again.

Plugging in an ethernet cable and rebooting allowed some of my daily backup script to run, docker configs from the RPi3B were backed up to the RPi400EHD mount, but then when being copied back to the RPi3B’s SSD, I ran into trouble again:

20260524_130841
20260524_1308411453×1453 628 KB

8

Next step… I turned off the wifi in dietpi-config, I still got errors, but that’s when I learnt the RPi3B’s ethernet and wifi have different mac addresses and without the wifi’s mac address binding, it got a new IP address. Binding the IP to the ehternet’s mac seems to have resolved the issue.

I think maybe the pi was struggling to power the wifi, even though I have an official power supply. Let me know if there’s any specific logs you want to see now that I can get to them. I would prefer not to have an ethernet cable but it’s not the end of the world.

9

Powering issues should be visible via the kernel logs, you can check them with dmesg.

10

dmesg only shows logs since the last reboot, the only error is this (which may be relevant given the wifi and bluetooth share a module I think):

[   10.413324] Bluetooth: hci0: BCM: firmware Patch file not found, tried:
[   10.415694] Bluetooth: hci0: BCM: 'brcm/BCM43430A1.raspberrypi,3-model-b.hcd'
[   10.415706] Bluetooth: hci0: BCM: 'brcm/BCM43430A1.hcd'
[   10.420098] Bluetooth: hci0: BCM: 'brcm/BCM.raspberrypi,3-model-b.hcd'
[   10.420104] Bluetooth: hci0: BCM: 'brcm/BCM.hcd'

journalctl had a lot of name conflict and multi-response warnings which sounded harmless but nonetheless I’ve changed the hostname, workgroup and local/domain/preferred master for one of the pis to remove those.

I now also see DietPi doesn’t have persistent logs by default so I assume there’s nowhere else to look unless I undo my fixes to recreate the issue?

11

OK so problem not quite solved… still getting these errors (although less frequently / not so quickly after booting):

20260525_211901
20260525_2119011545×1545 622 KB

Currently qbbittorrent’s incomplete downloads folder is on the RPI400’s HDD, I’m thinking of moving it to the SSD to reduce the number of random writes on the HDD but it feels like I’m just avoiding the issue rather than fixing it.