All my smb file transfers (Ctrl-X/Ctrl-V from/to network share using dolphin) get stuck after a few MB. Only very small files (few KB) get transferred successfully but when opening the file, dolphin just gets stuck: file not opening, dolphin UI not responding. Then Dolphin can’t be closed and trying to open “System Monitor” does not work: Icon just disappears from task manager after a moment. Same happens with any other app: no program can be started at this point.
After smb gets stuck, trying to start a program in Yakuake: after pressing enter, a new line with a rectangle appears, nothing else.
After smb gets stuck, rebooting the computer also does not work: it gets stuck after closing the task manager, keeps showing the desktop with widgets, tty can’t be opened so I have to use Reset.
Good idea, but SMART was ok and chkdsk found no problems.
Since the share can’t be unmounted in Dolphin (“target busy” despite cancelled transfer), I had to use umount -l /path/to/share . But even after that, new programs can’t be started and shutdown/logout will hang, so I always have to use Reset.
The issue also occurs when transferring files between the manjaro computers, so it isn’t a windows issue. In one case, the transfer was stuck at 60%, after pressing F5 in Dolphin, I got the message Information - Dolphin “Could not read file /path/to/file”, I selected “Retry” and the transfer ran to completion.
To check if the network switch was going bad, I ran ping and started the data transfer, assuming that if the transfer got stuck and the ping time became longer, it would point to a network issue but every time the transfer slowed down, the ping time got shorter. To my understanding that would indicate that the packages are not sent for some reason.
The issue persists, switching to an older kernel did also not help. Stable internet speeds seem to further prove that the hardware works correctly.
What can I do?
and mounting the shares via fstab; similar to this mentioned in the Arch Forum. Adding noauto as suggsted in that thread might provide smoother sailing.
So I used sudo aa-complain /etc/apparmor.d/usr.sbin.smbd, tried moving some files and it seemed to work, but then I moved some more and it got stuck again.
On one occasion, there was an error notification when trying to start a program after file transfer got stuck:
Launching Add/Remove Software (Failed)
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
To rule out apparmor, I removed the apparmor=1 security=apparmor (assuming this disables it) from GRUB_CMDLINE_LINUX_DEFAULT= in /etc/default/grub, but after update-grub and reboot, file transfers still get stuck.
Applying Stable Update 2024-12-16 did not help as well.
I don’t. But I might, and if I do, I won’t remember to turn it on
It should be disabled without the grub entry, so uninstalling it would not make a difference, right?
I think I used that sudo aa-complain /etc/apparmor.d/usr.sbin.smbd command once in the past when there was an apparmor error in systemctl status smb.service and it fixed it back then. Does the current output seem okay?
The smb.service is for running a fileserver - you don’t need the samba package on the client.
The only thing you need for the smbclient to function is an empty /etc/samba/smb.conf
You have only mentioned client side connection - no mention of how you have configured the server - a mention that may not be applicable if you do not run a Manjaro Samba Fileservice.
Exactly what kind of fileserver is this remote pc?
It is quite possible that you should look into the configuration of this file service.
