F44 Dolphin Gwenview becomes unresponsive on launch

Ask Fedora
1

Adding my experience in case it helps others landing here, as I had the same symptom (Dolphin frozen for 20–30 s on every launch, file pickers too), and Gwenview also affected. The testparm “Weak crypto is allowed by GnuTLS” line turned out to be a red herring on my system; there were three separate causes.

System

  • Fedora 44 KDE Plasma (Wayland), kernel 7.1.13-200.fc44

  • Intel i9-14900K, RTX 4070 Ti SUPER (NVIDIA proprietary driver), 64 GB DDR5

  • Samba running with a share for a libvirt Windows VM

How I tracked it down

Timestamped Qt debug logging, then looking for the biggest gaps:

QT_MESSAGE_PATTERN="%{time hh:mm:ss.zzz} %{category}: %{message}" \

QT_LOGGING_RULES="*.debug=true" dolphin > ~/dolphin-full.log 2>&1



awk '{split($1,t,"[:.]"); s=t[1]*3600+t[2]*60+t[3]+t[4]/1000; if (p && s-p>1) {printf "\n=== %.1fs gap ===\nBEFORE: %s\nAFTER:  %s\n", s-p, prev, $0}; if (t[4]!="") {p=s; prev=$0}}' ~/dolphin-full.log

The line before each gap shows what the app was waiting on. Note that time dolphin showed almost no CPU use, so it was waiting, not working.

Cause 1: duplicate fstab entry for an NTFS drive (~20 s, Dolphin + Gwenview)

The same NTFS partition was in /etc/fstab twice: once read-only at /run/media/…, once as an automount at /mnt/… KDE’s Places code touches every mount on startup, which triggered the automount; it can’t mount an already-mounted NTFS partition a second time, so it failed after 10 s, twice. The journal showed it clearly:

journalctl -b | grep -iE "automount|dependency"

# mnt-archive4tb.automount: Got automount request ... triggered by gwenview

# Dependency failed for mnt-archive4tb.mount

A quick way to spot a slow mount:

findmnt -rn -o TARGET | while read -r m; do m=$(printf '%b' "$m"); s=$(date +%s%N); timeout 30 stat -f "$m" >/dev/null 2>&1; e=$(date +%s%N); echo "$(( (e-s)/1000000 )) ms  $m"; done | sort -rn | head

Fix: commented out the duplicate line, then systemctl daemon-reload.

Cause 2: Dolphin’s Samba sharing plugin calling net usershare info (~24 s)

Right after the testparm log line, Dolphin runs net usershare info, which took 24 s. I had an old leftover usershare as well. Note that Fedora’s samba-usershares package adds include = /etc/samba/usershares.conf to smb.conf, which overrides any usershare max shares you set in [global].

Fix: set usershare max shares = 0 in /etc/samba/usershares.conf, restarted smb, and ran net usershare delete . (Removing kdenetwork-filesharing also works if you don’t use right-click sharing.)

Cause 3: interfaces = virbr0 in smb.conf (~8 s)

net was still taking 8 s just to say “usershares are currently disabled”. strace showed it waiting on systemd-resolved, and sudo resolvectl monitor revealed it was looking up virbr0 as a hostname. The LLMNR lookup took ~4 s to fail, and it happened twice.

Fix: used the bridge’s address instead of its name:

interfaces = lo 192.168.122.1/24

Result

Dolphin and Gwenview both open instantly again.

A note on how this was done

I’m a retired engineer rather than a Linux specialist, so I worked through this interactively with Anthropic’s Claude AI assistant. It suggested each diagnostic command, and I ran them and pasted back the output. It took a few wrong turns (Samba crypto, the portal, snapd, and even a BIOS update were all ruled out along the way), but the “measure the gap, see what’s on the line before it” approach got me there in the end.

2

Can you say why you need the interfaces = virbr0 in smb.conf?
I do have that on my server, but I also do not have a bridge device on the server.

Also it seems like a bug that samba looks up in dns name on the interface.

3

This is odd. Normally those /run/media mounts are created dynamically at runtime and wouldn’t have an entry in /etc/fstab.

Do you know how the entry in /etc/fstab got there?

4

Thanks Barry, good question.

Why interfaces = virbr0: the Samba share on this PC only exists so a libvirt Windows VM can map a folder on the host (\\192.168.122.1\vmshare). virbr0 is libvirt’s default NAT bridge, so I had:

interfaces = lo virbr0
bind interfaces only = yes

That keeps Samba listening only on the VM’s private network, not on my home Wi-Fi. If you don’t have a bridge or VMs, there’s no reason to have it; on a server you’d normally list the LAN interface or subnet instead.

On the DNS lookup: agreed, it looks odd. The interfaces option accepts interface names, IP addresses, subnets or hostnames, and on my system net clearly tried resolving virbr0 as a host before matching it as an interface. sudo resolvectl monitor showed:

→ Q: virbr0 IN A
→ Q: virbr0 IN AAAA
← S: not-found

(twice, ~4 s each).

I think the delay is really the combination with Fedora’s systemd-resolved defaults: LLMNR=resolve is on, so a single-label name like virbr0 gets sent out as an LLMNR query and only fails after the timeout. On a system without LLMNR the failed lookup would probably return instantly and nobody would notice.

So there are two possible fixes:

  • use the address instead of the name (what I did): interfaces = lo 192.168.122.1/24
  • or disable LLMNR in resolved (LLMNR=no in a /etc/systemd/resolved.conf.d/ drop-in)

Whether Samba should try DNS first for something that matches a local interface name is a fair question. It might be worth a bug report upstream if others can reproduce it.

5

You’re right, and that’s a good point. I don’t know for certain how it got there, I’m afraid.

Looking back, the drive has had its UUID change (it was re-formatted/repaired at some point), and I’ve been through a few rounds of trying to get it mounting reliably at a fixed path for a symlinked photo archive. My best guess is that one of those attempts added a line using the path the drive happened to be auto-mounted at, /run/media/bob/ARCHIVE, either by hand or via a partition/mount-options tool that pre-fills the current mount point. Later I added the proper /mnt/archive4tb automount line without realising the old one was still there, pointing at the same UUID.

The lines were:

UUID=2E5CC5CE5CC5914F  /run/media/bob/ARCHIVE  ntfs-3g  ro,uid=1000,gid=1000,nofail,x-systemd.automount,x-systemd.idle-timeout=...
UUID=2E5CC5CE5CC5914F  /mnt/archive4tb         ntfs-3g  nofail,x-systemd.automount,x-systemd.idle-timeout=10min,...

Lesson learned: /run/media should be left to udisks, and one fstab entry per partition. If anyone else sees an automount unit failing with “Dependency failed” while the drive is visibly mounted elsewhere, a quick check is:

grep -v '^#' /etc/fstab | awk '{print $1}' | sort | uniq -d

That lists any UUID that appears more than once.

6

that is correct, and is usually only used for communications between the host and VMs. Using a different bridge that you manually configure is better (more reliable and consistent) for communications between a VM and your LAN. Using the same bridge from the host to the VM and from the VM to the LAN seems likely to be problematic.

7

You only need the bridge if you want the vm to see the lan directly, e.g. no NAT I thought.
I use a bridge and all my VMs DHCP to as if directly connected to the lan.

You do not need a bridge to go from guest to host as far as I remember.

8

AFAIK and IME virbr0 is used to enable direct connections from host to VM. It is the default bridge created when a VM is booted and seems to disappear when the VM is shutdown. You are correct that you can go from guest to host without a bridge, but the bridge seems required to go from host to guest because of the default NAT configs.

When I create a VM I select its config to use virbr0 instead of the default NAT for networking. I then have access directly to the VM from the host for ssh, and other tools.

NAT hides the IP of the VM machine and makes it very difficult to communicate from host to VM.

As I understand it a user may create as many bridge devices as they choose which are bound to the external network interface, and then can use that bridge device so the VM has direct access to an external interface on the lan without relying on the host for forwarding or for NAT.

Virbr0 seems bound by default to the virtual network interface of the (one or many) VMs.