Filemanagers (Thunar,Dolphin) unresponsive when browsing unconnected network share

General system Newbie
1

Hello everyone :slight_smile:

This is probably not directly related to EOS because after searching the whole day for a solution I came across a lot of other topics on github with similar issues.

Everything worked as expected over a year with Thunar but now I came across this issue that seems to be independent from OS/filemanager. I have 4 samba network share in my /etc/fstab

//192.168.1.37/navidrome_media /mnt/navidrome_media smb3 uid=1000,gid=1000,credentials=/root/.smbcredentials,dir_mode=0755,file_mode=0644,nofail,noatime,noauto,x-systemd.automount,_netdev,x-systemd.mount-timeout=5 0 0
//192.168.1.37/komga_media /mnt/komga_media smb3 uid=1000,gid=1000,credentials=/root/.smbcredentials,dir_mode=0755,file_mode=0644,nofail,noatime,x-systemd.automount,_netdev 0 0
//192.168.1.37/sonarr_media /mnt/sonarr_media/ smb3 uid=1000,gid=1000,credentials=/root/.smbcredentials,dir_mode=0755,file_mode=0644,nofail,noatime,x-systemd.automount,_netdev 0 0
//192.168.1.37/zotero_media /mnt/zotero_media smb3 uid=1000,gid=1000,credentials=/root/.smbcredentials,dir_mode=0755,file_mode=0644,nofail,noatime,x-systemd.automount,_netdev 0 0

I have these shares bookmarked to the left side of Thunar and are only mounted when accessed (x-systemd.automount) and while it worked without issue for over a year, now when I’m trying to open Thunar it hangs and is unresponsive for a long time (maybe over a minute) when these network shares are offline. It seems like Thunar is trying to access those shares because they are bookmarked, but that wasn’t the case a few days ago.

Same behavior is observed with Dolphin which is a known issue (dolphin-slow-when-remote-mount-off-line).

Nemo also seems to suffer from the exact issue HOWEVER, nemo seems to work on my side. I can open nemo and as long as I don’t try to access offline shares it’s working as expected.

What’s going on here? Thunar used to work a few days ago and now It just take minutes to even respond. Has anyone any clue how to solve this issue or where I should look? Any alternative?

System:

EOS XFCE4

dmesg logs:

[ 2520.348496] CIFS: VFS: \\192.168.1.37 has not responded in 180 seconds. Reconnecting...
[ 3713.941232] CIFS: VFS: \\192.168.1.37 has not responded in 180 seconds. Reconnecting...
[ 4038.206055] CIFS: VFS: \\192.168.1.37 has not responded in 180 seconds. Reconnecting...

Other related issues:
https://bugs.kde.org/show_bug.cgi?id=448361

Edit:

I tried the following solution from arch linux wiki (slow cold start) but that didn’t helped either.

2

Hello Kalia,

Try the option “soft” in the fstab:

//192.168.1.37/komga_media /mnt/komga_media smb3 soft,[...]

3

Hello, Thanks for your reply ! Sorry for the late response…

I gave it a try and doesn’t work as expected.

I noticed something while doing some stuff around the /mnt folder. Normally when I tried to access this folder, which contains my mounted network volumes, nothing really happened because I’m not accessing any network volume directly (/mnt/zotero_media) however now when I try to access the /mnt directory i tries to mount every volume present in that directory, which wasn’t the case before.

So this isn't a thunar issue but how the `x-systemd.automount` options works in the `/etc/fstab`. The automount trap seems to work differently than before, and tries to mount every volume present in `/mnt` when accessing this directory.

I gave Nemo a try (another filemanager) and this works as expected. When I open Nemo and the network mounted volumes are offline, it doesn’t try to access them and doesn’t hang or whatsover… In thunar just trying to hover the unmounted volume makes the whole filemanager hang.

So this is probably a Thunar issue and I will probably forward this post over there.

Thanks again for your response !

4

Thanks for sharing the bug URL’s.

I’m experiencing the same issue within the kde environment, so dolphin, kdepartionmanager and context menu file operations. I use systemd-automount units to occasionally connect external hard drives for backups.
My workaround is systemctl disable --now xxx.automount for the most time, and when I want to use the external hard drive, systemctl enable --now ..... Not ideal, I know.
Also, PCManFM file manager is not having this issue.
So, the issue appear to be kde file operations not compatible with systemd automount units, or in your case XFCE / Thunar file operations.

1 Like
5

So, the issue appear to be kde file operations not compatible with systemd automount units, or in your case XFCE / Thunar file operations.

Thanks for the pointer ! In KDE’s native file manager it’s a 4 years old bug, and in the case of Thunar it just appeared after the lasted XFCE update (4.20). Right now I’m not comfortable enough with EOS/Arch bleeding-edge updates to downgrade XFCE and all it’s dependencies to test the claim without breaking the whole OS…

My workaround is systemctl disable --now xxx.automount for the most time, and when I want to use the external hard drive, systemctl enable --now ..... Not ideal, I know.

I will keep this workaround in mind if Nemo also breaks after some kind of update and is still not fixed :). Nemo seems rather stable and behaves how Thunar used to work before all this. I still need to roam XFCE’s forum see if anyone else has reported a similar issue.

Side note: I’m running KDE Plasma with Nemo right now and it seems to work :slight_smile: If you’re tired to always disable/enable the automount daemon give it a try !

6

Hey @Goyano !

This morning on startup KDE plasma 6 was very slow on startup and took a long time to boot into the desktop, after changing the TTY console I saw that even on boot it tries to mount the unconnected network drive:

VFS: cifs_mount failed code -4/-113
Error connecting to socket
...

So I tried with a systemd.mount/systemd.automount unit files. While this solved the boot issue, the file manager issue remains.

The systemd.automount status logs shows that it tries to mount the drive as soon as I open Thunar or Dolphin:

sudo systemctl status mnt-navidrome_media.automount

jan 07 13:59:32 endeavourOS systemd[1]: Set up automount cifs automount unit.
jan 07 14:01:33 endeavourOS systemd[1]: mnt-navidrome_media.automount: Got automount request for /mnt/navidrome_media, triggered by 1506 (Thunar)
jan 07 14:01:37 endeavourOS systemd[1]: mnt-navidrome_media.automount: Got automount request for /mnt/navidrome_media, triggered by 1508 (gmain)
jan 07 14:01:48 endeavourOS systemd[1]: mnt-navidrome_media.automount: Got automount request for /mnt/navidrome_media, triggered by 1508 (gmain)
jan 07 14:01:57 endeavourOS systemd[1]: mnt-navidrome_media.automount: Got automount request for /mnt/navidrome_media, triggered by 1508 (gmain)
jan 07 14:02:07 endeavourOS systemd[1]: mnt-navidrome_media.automount: Got automount request for /mnt/navidrome_media, triggered by 1508 (gmain)
jan 07 14:02:16 endeavourOS systemd[1]: mnt-navidrome_media.automount: Got automount request for /mnt/navidrome_media, triggered by 1508 (gmain)
jan 07 14:02:25 endeavourOS systemd[1]: mnt-navidrome_media.automount: Got automount request for /mnt/navidrome_media, triggered by 1508 (gmain)
...

This goes one forever as long as Thunar is open. In conclusion the only combo that works in my setup XFCE + Nemo.

7

The way I’ve approached this, is instead of using /etc/fstab to mount the shares, I use a script file I run only when I want to access the shares on my NAS. That script file will test if the server is online, and if it is, proceed to mount the shares.

The advantage here is it’s not trying to access something that’s not available (such as when I’m out and about on my laptop, with no NAS). The script can also include other post mount actions if you want, like synchronising certain files to and from your network shares.

This is written in bash, so the script file may be called something like mountSMB.sh, and you might put it on your desktop so you can just double click it when needed. My shares are SFTP, but I’ll adapt the server test and mount commands for SMB (or try to at least).

#!/bin/bash

# Test if SMB server is answering
timeout 5 bash -c "</dev/tcp/192.168.1.37/139"
if [ $? != 0 ];then
   # SMB unresponsive
   echo "SMB server unresponsive."
   exit 1
fi

That will test your SMB server (192.168.1.37) on TCP port 139 (assuming that’s the correct port). If it fails to respond within 5 seconds, the script exits and it doesn’t attempt to mount shares. Next in the script file, you might then mount your shares.

I haven’t used SMB in a while, so this is just best guess, you might need to revise:

mount -t cifs //192.168.1.37/navidrome_media /mnt/navidrome_media -o credentials=/root/.smbcredentials,uid=1000,gid=1000,dir_mode=0755,file_mode=0644
mount -t cifs //192.168.1.37/komga_media /mnt/komga_media -o credentials=/root/.smbcredentials,uid=1000,gid=1000,dir_mode=0755,file_mode=0644
mount -t cifs //192.168.1.37/sonarr_media /mnt/sonarr_media -o credentials=/root/.smbcredentials,uid=1000,gid=1000,dir_mode=0755,file_mode=0644
mount -t cifs //192.168.1.37/zotero_media /mnt/zotero_media -o credentials=/root/.smbcredentials,uid=1000,gid=1000,dir_mode=0755,file_mode=0644
2 Likes
8

Thanks for sharing your knowledge/script ! I do prefer the auto-mount trap in fstab though because it’s somehow automated when trying to access the shared folder. But it’s a very good alternative in case Nemo also breaks on me.

Still, I’m not sure if this is the normal behavior or a bug related to how the file manager tries to access those folders.