Smb file transfer stuck since Stable Update 2024-11-30

Support Network
1

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.

Rebooting the remote pc did not help.

May be same issue that was reported here without solution [Stable Update] 2024-11-30 - Kernels, Plasma, GNOME, COSMIC, LXQT, SYSTEMD - #113 by Riquez

Please help.

System:
  Kernel: 6.12.1-4-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 14.2.1
    clocksource: tsc
  Desktop: KDE Plasma v: 6.2.4 tk: Qt v: N/A wm: kwin_x11 vt: 2 dm: SDDM
    Distro: Manjaro base: Arch Linux
Machine:
  Type: Desktop System: Gigabyte product: Z690 AORUS MASTER v: -CF
  Mobo: Gigabyte model: Z690 AORUS MASTER
CPU:
  Info: 24-core (8-mt/16-st) model: 13th Gen Intel Core i9-13900K bits: 64
Audio:
  Device-1: Intel Alder Lake-S HD Audio vendor: Gigabyte driver: snd_hda_intel
    v: kernel bus-ID: 00:1f.3 chip-ID: 8086:7ad0 class-ID: 0403
  Device-2: NVIDIA AD102 High Definition Audio driver: snd_hda_intel
    v: kernel pcie: speed: 16 GT/s lanes: 16 bus-ID: 01:00.1 chip-ID: 10de:22ba
    class-ID: 0403
  API: ALSA v: k6.12.1-4-MANJARO status: kernel-api with: aoss
    type: oss-emulator
  Server-1: sndiod v: N/A status: off
  Server-2: JACK v: 1.9.22 status: off
  Server-3: PipeWire v: 1.2.7 status: off with: pipewire-media-session
    status: off
  Server-4: PulseAudio v: 17.0 status: active with: 1: pulseaudio-alsa
    type: plugin 2: pulseaudio-jack type: module
Network:
  Device-1: Intel Alder Lake-S PCH CNVi WiFi driver: iwlwifi v: kernel
    bus-ID: 00:14.3 chip-ID: 8086:7af0 class-ID: 0280
  IF: wlo1 state: down mac: <filter>
  Device-2: Aquantia AQC113C NBase-T/IEEE 802.3an Ethernet [Marvell
    Scalable mGig] vendor: Gigabyte driver: atlantic v: kernel pcie:
    speed: 8 GT/s lanes: 2 port: N/A bus-ID: 02:00.0 chip-ID: 1d6a:14c0
    class-ID: 0200 temp: 42.0 C
  IF: enp2s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Swap:
  Alert: No swap data was found.

Info:
  Memory: total: 32 GiB available: 31.16 GiB used: 7.98 GiB (25.6%)
  Processes: 469 Power: uptime: 33m states: freeze,mem,disk suspend: deep
    wakeups: 0 hibernate: platform Init: systemd v: 256 default: graphical
2

I cannot reproduce your issue.

I just copied a 3.3G iso from my network -using smb - to a test laptop running Manjaro Plasma stable branch.

It is impossibly to suggest anything when not easily reproduced.

One would suspect anything from a custom package to a network driver issue.

Please provide some system info

 inxi -Fxxx

Copy the textual output and paste it into your original topic - then mark the pasted text and click the button </> in the topic toolbar.

3

Tried it on a second manjaro computer on update 2024-11-30 and after one successful file transfer, the issue is present there, too.

4

You might consider checking the destination filesystem for consistency.

5

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.

6

Please sync your system to the latest version.

7

I already am on stable update 2024-12-06.

8

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?

9

You might try using CIFS instead;

sudo pacman -S cifs-utils

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.

10

cifs is an implementation of smb (between smb1 and smb2) and no longer developed and should definately not be used in any serious environment.

You issue is a local issue and not reproducable.

I may be caused by apparmor, see → [root tip] [How To] Basic Samba Setup and Troubleshooting

11

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.

12

Unless you use snap you can safely remove appmor

I have no idea what conditions on your local system which interferes with network file transfers.

What I can say - samba works on a default Manjaro installation - without any issues.

This means - frustrating for your as it is - it is a local issue - I have no means of suplying information which may help you resolve your issue.

13

I don’t. But I might, and if I do, I won’t remember to turn it on :wink:
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?

systemctl status smb.service
○ smb.service - Samba SMB Daemon
     Loaded: loaded (/usr/lib/systemd/system/smb.service; disabled; preset: disabled)
     Active: inactive (dead)
       Docs: man:smbd(8)
             man:samba(7)
             man:smb.conf(5)
14

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.

15

An old windows computer without updates and - for obvious security reasons - also without internet access. Never change a running system and it has worked perfectly for years. So there was no recent software or hardware change that could have caused an issue on that side.

On windows (“server” side), it is configured without using HomeGroup. Advanced Sharing, a separate user with its own credentials and using that user / password to access the shares from manjaro.

You are right, kdenetwork-filesharing and samba can be removed (but did not improve file transfer).
Wait, so you mean that the samba update contained in stable update 2024-11-30 is unlikely to be the cause of my issues because that package is not needed to access files on another computer?

At about the same time this started, I cleared out some orphan packages. Although I checked every package, maybe something was still required. At least it broke the theming for some apps.

Regarding apps not starting after file transfer got stuck:

  • Remmina/Firefox/Thunderbird/Brasero still start
  • Gparted still starts but keeps scanning /dev/sda indefinitely
  • Calc/Terminal/LibreOffice Writer/System Settings/Gwenview/Dolphin/Ark/pamac don’t start
    Is this only GTK apps being less affected? If so, this could also point to the removed orphan packages.
16

There was yet an update to stable branch on 24-12-16.

That sounds like a filesystem issues - I don’t see the connection.

What I am saying is: Only the smbclient package and kio, kio-extras or gvfs, gvfs-smb is required to access a samba share.

As such I don’t think an update to the server side samba package changes the client side smbclient package.

just a thought

Your assumption that something has changed on the client may be correct. Your fileservice - is it Windows 7 or Windows XP?

A grasp in the dark - if on Windows 7 - there is a small chance that you can add to your client system /etc/samba/smb.conf.

There is a nice overview over the protocols at cybercity.biz

Edit your client’s /etc/samba/smb.conf

[global]
 client max protocol = SMB2

known kde regression

I saw somewhere that kio (the kde backend for among other things smb) and dolphin has regressions.

see → buglist - dolphin → smb keyword
see → buglist - frameworks-kio → smb keyword

For various reasons I don’t use dolphin in production (in an attempt to verify your issue I conducted some test on a dedicated stable test system running Plasma on stable branch - where I could not reproduce the issue), instead I use pcmanfm-qt as filemanager and gvfs-smb (smbclient) to access SMB shares.

//EDIT:

After some experimentation back and forth and I have been able to reproduce the issue in my production environment.

environment

  • Manjaro edge branch
  • plasma 6.2.4
  • frameworks 6.9.0
  • qt version 6.8.1

packages

  • dolphin 24.12.0
  • kio-extras 24.12.0
  • pcmanfm-qt 2.1.0
  • gvfs-smb 1.56.1
  • smbclient 2:4.21.2

test dolphin

  • open a samba fileshare in dolphin (authenticated user)
  • share as seen in dolphin → open file manager (F4)
    08:17:59 ○ [fh@tiger] .../transit/test
 $ echo $PWD
/run/user/1000/kio-fuse-wywaAE/smb/fh@pw1.net.nix.dk/transit/test

08:18:37 ○ [fh@tiger] .../transit/test
 $ du -h .
9,9G    .
  • drag’n’drop several giga byte data (4 iso files) to a test share on a samba test fileservice opened with dolphin.
  • The transfer popup takes a long time to open - one began to speculate if it actually worked.
  • Eventually it did - and the speed was as expected considered the test environment. (rpi4b8G running of an USB attached 500G ssd).
  • Using dolphin to copy back the data fails
    • copy/paste of one or more files does not work
    • drag’n’drop one or more files does not work

test pcmanfm

  • Opening the share using pcmanfm and repeating the copy-back work with no issues
  • share as seen in pcmanfm → open terminal (F4)
    08:20:48 ○ [fh@tiger] .../smb-share:server=pw1.net.nix.dk,share=transit/test
 $ echo $PWD
/run/user/1000/gvfs/smb-share:server=pw1.net.nix.dk,share=transit/test

08:20:57 ○ [fh@tiger] .../smb-share:server=pw1.net.nix.dk,share=transit/test
 $ du -h .
9,9G    .

deductions from the above results

  • It is not samba which causes issues neither the file service.
  • pcmanfm uses gvfs and gvfs-smb
  • It is likely a regression likely the kio backend (mentioned above and in other places).
  • I recall that one or more issues on the matter already exist with KDE

course of action

Manjaro does not fix upstream problems - so your only option is to file a bugreport with bugs.kde.org.

possible solution

Until such time that upstream fixes the issue(s) the following will solve your immediate issue.

Use pcmanfm instead of dolphin (there are more plugins to gvfs - I only listed the two necessary for Windows network shares/discovery)

sudo pacman -Syu pcmanfm-qt gvfs-smb gvfs-wssd

If you remove dolphin - pcmanfm will become the default filemanager.

1 Like
17

You figured it out - that’s awesome, thank you so much!

I installed the update but it did not help, unfortunately.

If I start gparted before a file transfer gets stuck, scanning for filesystem takes less than a second.

It’s Win 8, so I added client max protocol = SMB3 to my smb.conf but without effect.

It works, thank you!
Only weird thing is that pcmanfm does not offer a “write into” option like Dolphin when pasting a folder to a location where a folder of the same name already exists. It only offers to overwrite which seems really dangerous when you’re coming from Dolphin, expecting the other question.

Also I noticed that I had actually configured it like @soundofthunder suggested, so I did not have to enter my credentials every time. Usually, I would leave it there for when the bugs gets fixed, but since you said cifs should be avoided: can I just replace cifs with gvfs-smb or something here in fstab
//RemotePC/Disk1 /mnt/RemotePC/Disk1 cifs noauto,users,credentials=/path/to/credentials,file_mode=0644,dir_mode=0755 0 0
or would it be more difficult?

18

The cifs suggestion was a possible temporary solution until any Dolphin issues were resolved; because cifs remains available in Manjaro repo’s; but, wasn’t meant for continued use.

However, if you already had those entries in fstab from previous tinkering then I’m guessing they were conflicting.

I would remove those entries (or at least comment them).

1 Like
19

I had it like that for years because I could not mount the shares in Dolphin otherwise back then. Also this way all the shares are neatly listed under Remote in the places panel.

Now, after removing the entries, there are again problems accessing the shares in Dolphin: no write access (at least in topmost directory), no option to save credentials, asking for credentials for each subfolder, too and then not accepting them.
So without these entries, Dolphin is still not able to handle shares in a usable manner, at least on my computer.

20

Well - it means the same thing.

Perhaps the Write Into is linguistically a better wording - but in the context of a folder - it means the same as Overwrite.

But it has been an ongoing debate for years, Should it be Rename or Write Into or something else?

When you mount in fstab using this, using the noauto option, the mount may or may not be available on boot.

I strongly suggest you use a mount/automount combo with the _netdev option as this will ensure the share is only mounted when the mountpoint is accessed (remember to comment the fstab entry)

Create the following files

cat << EOF > /etc/systemd/system/mnt-RemotePC-Disk1.mount
[Unit]
Description=Remote PC Disk1

[Mount]
What=//RemotePC/Disk1
Where=/mnt/RemotePC/Disk1
Type=cifs
Options=_netdev,rw,credentials=/path/to/credentials,file_mode=0644,dir_mode=0755,vers=3
TimeoutSec=30

EOF

cat << EOF > /etc/systemd/system/mnt-RemotePC-Disk1.automount
[Unit]
Description=Remote PC Disk1
ConditionPathExists=/mnt/RemotePC/Disk1

[Automount]
Where=/mnt/RemotePC/Disk1
TimeoutIdleSec=10

[Install]
WantedBy=multi-user.target

EOF

Then enable the automount unit (do not enable the mount unit)

The system will detect (using the automount unit) accessing the mountpoint and start the mount unit in the background.

sudo systemctl enable --now mnt-RemotePC-Disk1.automount
1 Like