Why is kded6 triggering an auto-mount-request on login?

I run openSUSE Tumbleweed

Operating System: openSUSE Tumbleweed 20250624
KDE Plasma Version: 6.4.0
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.15.3-1-default (64-bit)
Graphics Platform: X11
Graphics Processor: Intel® Iris® Xe Graphics

which I update with zypper dup on a nearly daily basis. On login a small script will show me the result of journalctl --no-hostname --no-pager --full --utc -b 0 -p 3. Since by the end of last week I see (on login) this error message:

Jun 26 14:50:08 kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Jun 26 14:50:08 kernel: CIFS: VFS: cifs_mount failed w/return code = -101
Jun 26 14:50:08 systemd[1]: Failed to mount /mnt/LAN/QNAP_Backups.

However I have not discovered any other problems so far i.e. after login I can access the device in question without any problems.

If I boot my system (to graphical.target) but do not login and instead change to a virtual terminal (e.g. Ctrl+Alt+F3) and check the journal, the error has not yet occured. After login (I use SDDM as DisplayManager) the error is there.

There is a line in /etc/fstab to handle the device:

//192.168.100.19/Backups  /mnt/LAN/QNAP_Backups      cifs    nofail,rw,_netdev,credentials=/PATH/TO/CREDENTIALS,uid=1000,gid=1000,sec=ntlmsspi,cache=none,nohandlecache,soft,x-systemd.automount,x-systemd.mount-timeout=30,x-systemd.idle-timeout=300s 0 0

To my understanding the device should only be mounted on demand, i.e when I try to access the device which I obviously will not do while the login process is still in progress.

Inspecting the journal more closely I can see

> journalctl --no-hostname --no-pager --full --utc -b 0
...
Jun 26 14:50:07 systemd[1864]: Started KDE Config Module Initialization.
Jun 26 14:50:07 systemd[1864]: Starting KDE Daemon 6...
Jun 26 14:50:07 systemd[1864]: Starting KDE Session Management Server...
Jun 26 14:50:07 systemd[1864]: Starting KDE Window Manager...
Jun 26 14:50:07 kded6[2044]: MESA: warning: Support for this platform is experimental with Xe KMD, bug reports may be ignored.
Jun 26 14:50:07 systemd[1864]: Started KDE Daemon 6.
Jun 26 14:50:07 systemd[1864]: Starting KDE Configuration Module Initialization (Phase 1)...
Jun 26 14:50:07 ksmserver[2045]: MESA: warning: Support for this platform is experimental with Xe KMD, bug reports may be ignored.
Jun 26 14:50:07 kwin_x11[2046]: MESA: warning: Support for this platform is experimental with Xe KMD, bug reports may be ignored.
Jun 26 14:50:07 kded6[2044]: QDBusObjectPath: invalid path "/modules/wpad-detector"
Jun 26 14:50:07 kded6[2044]: kf.dbusaddons: The kded module name "wpad-detector" is invalid!
Jun 26 14:50:07 kcminit_startup[1996]: Initializing  "/usr/lib64/qt6/plugins/plasma/kcms/systemsettings/kcm_touchpad.so"
Jun 26 14:50:07 kcminit_startup[1996]: kcm_touchpad: Using X11 backend
Jun 26 14:50:08 systemd[1864]: Finished KDE Configuration Module Initialization (Phase 1).
Jun 26 14:50:08 systemd[1864]: Started KDE Session Management Server.
Jun 26 14:50:08 systemd[1864]: Starting KDE Plasma Workspace...
Jun 26 14:50:08 systemd[1864]: Started PipeWire PulseAudio.
Jun 26 14:50:08 systemd[1864]: Started KDE Window Manager.
Jun 26 14:50:08 rtkit-daemon[1896]: Successfully made thread 2170 of process 2170 owned by '1000' high priority at nice level -11.
Jun 26 14:50:08 rtkit-daemon[1896]: Successfully made thread 2173 of process 2170 owned by '1000' RT at priority 20.
Jun 26 14:50:08 systemd[1]: Starting Disk Manager...
Jun 26 14:50:08 NetworkManager[1484]: <info>  [1750949408.2074] agent-manager: agent[a2b1c621b1334a26,:1.35/org.kde.plasma.networkmanagement/1000]: agent registered
Jun 26 14:50:08 udisksd[2178]: udisks daemon version 2.10.1 starting
Jun 26 14:50:08 systemd[1]: Started Disk Manager.
Jun 26 14:50:08 systemd[1]: Starting Daemon for power management...
Jun 26 14:50:08 udisksd[2178]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Jun 26 14:50:08 systemd[1]: Started Daemon for power management.
Jun 26 14:50:08 systemd[1]: mnt-LAN-QNAP_Backups.automount: Got automount request for /mnt/LAN/QNAP_Backups, triggered by 2044 (kded6)
Jun 26 14:50:08 systemd[1]: Mounting /mnt/LAN/QNAP_Backups...
Jun 26 14:50:08 kernel: netfs: FS-Cache loaded
Jun 26 14:50:08 kernel: Key type dns_resolver registered
Jun 26 14:50:08 mount[2194]: mount error(101): Network is unreachable
Jun 26 14:50:08 mount[2194]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Jun 26 14:50:08 kernel: Key type cifs.spnego registered
Jun 26 14:50:08 kernel: Key type cifs.idmap registered
Jun 26 14:50:08 kernel: CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
Jun 26 14:50:08 kernel: CIFS: enabling forceuid mount option implicitly because uid= option is specified
Jun 26 14:50:08 kernel: CIFS: enabling forcegid mount option implicitly because gid= option is specified
Jun 26 14:50:08 kernel: CIFS: Attempting to mount //192.168.100.19/Backups
Jun 26 14:50:08 kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Jun 26 14:50:08 kernel: CIFS: VFS: cifs_mount failed w/return code = -101
...

I use NetworkManager to handle all network connections and I will start any connection only manually (via the plasma applet) when needed.

So my questions are:

Why is kded6 triggering an auto-mount-request even before the login process is finished?

Is anyone else seeing this?

How do I have to change my current setup to avoid this auto-mount-request?

To be clear: The problem suddenly occurred by the end of last week (probably after an update?) without me changing my setup deliberately.

Thank you very much for your support.

It does seem strange. Just a thought - Check System Settings > Device Auto-Mount for any unwanted configuration settings. It’s really designed for removable media, but perhaps something unexpected shown here?

Another thought - Is Baloo trying to index the network share? Check ~/.config/baloofilercand maybe explicitly exclude any unwanted directory paths.

Presumably the graphical login tries to mount prematurely. I am hiding several filesystems from udisks2:

erlangen:~ # cat /etc/udev/rules.d/61-hide-partitions.rules 
# Crucial 4TB SSD
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="47e6d9ee-e910-4ea4-8c8f-7ac75f49a4d3", ENV{UDISKS_IGNORE}="1"
# Seagate 8TB HDD
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="2260f160-cc05-47cc-9893-cc32c050177d", ENV{UDISKS_IGNORE}="1"
erlangen:~ # 

Udisks doesn’t mount remote file systems though, so irrelevant here.

@deano_ferrari , @karlmistelberger :

Thank you very much for looking into my problem!

System Settings > Device Auto-Mount
Is this referring to systemsettingsDisks & CamerasDevice Auto-Mount ? If so I do not have any entries there.

Baloo → should be disabled

> cat ~/.config/baloofilerc
[Basic Settings]
Indexing-Enabled=false

[General]
exclude folders[$e]=$HOME/
only basic indexing=true
>

udev-rules
I’m not too familiar with udev-rules. I will have to work out how to reliably address a network drive in an udev-rule. As soon as I have I will report back.

Don’t waste your time. Udev has nothing to do with your issue.

Are you starting with an empty desktop session? Is Dolphin opened and possibly triggering the auto-mount when starting up? Is the share in the ‘Places’ menu for example?

Yes, I always start with an empty session.

No.

Yes, it is and ever was even before that error turned up by the end of last week. Nevertheless I will remove it from “Places” and will report back.

Maybe another application accesses ~/.local/share/RecentDocuments/ and contains history involving the samba share? (Just speculation of course.)

You could trying clearing that with
rm ~/.local/share/RecentDocuments/*

Focusing on the journal log you shared…

Check
grep -i QNAP ~/.local/share/user-places.xbel

You could back up the existing file with
mv ~/.local/share/user-places.xbel ~/.local/share/user-places.xbel.old
then reboot and see if the mount attempt is gone.

@deano_ferrari :

My RecentDocuments folder is empty

> ls -la ~/.local/share/RecentDocuments
total 0
drwx------ 1 user1 user1    0 Jun 27 09:57 .
drwx------ 1 user1 user1 1510 Jun 27 10:56 ..
>

I did

  1. logout as user
  2. switch to a virtual terminal
  3. login as “root”
  4. move all /home/user1/.local/share/user-places.* files away (there were 4 of them)
  5. reboot the system

The error is still there.

But what surprises me even more is that dolphin still shows the drive in question in the “Places” section.

You don’t log in as root. Remove as the user in question. The file is likely still there for your user account.

It might be worth clearing the user’s ~/.cache/ directory as well.

Why should it?

I did as “root”

And by looking at the “Places” section of dolphin (after reboot and logged in as user1) one could see that there had been a new user-places,xbel file created. I always switch of the “Places” like “Documents” and they had been there again.

I will delete the .cache directory and report back.

Thank you very much for all your help!

I rebooted.

When the login prompt appeared I switched to a VT logged in as “root” and did

rm -r /home/user1/.cache

After that I verified that the directory was gone.

Then I logged out as “root”, switched to VT2 (GUI-Login screen) and logged in as user1.

The error was still there.

After this I used cockpit to create a new user “test”.

I shut down the machine, waited a few seconds and switched it on again. Booted into openSUSE Tumbleweed and as the very first logged in as user “test”. The error was there again.

To me this looks like the problem is not being caused by any configuration stored in the users HOME.

I have to admit that I’m completely lost. It is really a pity that the problem can’t be reproduced by someone else,

The problem still exists with openSUSE Tumbleweed 20250626.

I am not using Tumbleweed nor Plama6, but reading this I wonder if KDE tries to handle this as a “plug-in” device. The fact that it is since an update may trigger to find out which Plasma parts are in the update and then look for a release note about that. Or ask in the KDE forums.

True …

Last week while I was busy moving an older QNAP NAS from QTS to openSUSE Tumbleweed I updated my other systems regularly but did not pay much attention to the logs (my fault). So I cannot tell exactly when the problem started.

Having only a vague idea where to start checking the change logs I would prefer to avoid that task. Especially as the error message does not cause any obvious problem. However if there is no other way …

I didn’t see this mentioned but do you have a file called kded6rc?
There might be something triggering it from there?

I don’t have that file under my main user account but I do have one under my guest account located at /home/guest/.config/kded6rc

I have no clue why and all it has in it is this:

[PlasmaBrowserIntegration]
shownCount=3

Also, something may be going on with KDED6 and building the Sycoca database ( Sycoca stands for System Configuration Cache). I’m not sure if it pertains to network shares, but since it’s hiding we need to look everywhere.

https://man.archlinux.org/man/kded6.8.en