Thunar hangs on startup when unavailable network shares are in bookmarks

Alexander Schwinn @alexxcons said:

Thanks for reporting and sorry for the late reply !

I cannot reproduce the bug via samba, since I dont have a samba share. As far as I can see, I first need to add a bookmark for a samba share.

I added a reply on #12265 ... I believe both bugs are about the same problem, and I have a nfs mount .. so I replied there.

Could you please take a try for the suggestions there ? https://bugzilla.xfce.org/show_bug.cgi?id=12265#c1

Alexander Schwinn @alexxcons closed a related bug:

*** Bug 16687 has been marked as a duplicate of this bug. ***

Alexander Schwinn @alexxcons closed a related bug:

*** Bug 15789 has been marked as a duplicate of this bug. ***

Harald Judt said:

I can see this issue with thunar-1.8.14 and a hanging sshfs resource, but don't know of a way to reproduce the problem.

Similar issue in my related closed-duplicate bug... Discussing in https://forum.xfce.org/viewtopic.php?pid=60140 ...

Please note, I'm using autofs and have bookmarks to paths inside the nfs and cifs shares which leads to several issues like this:

With Thunar running, the autofs network shares are never released.
Thunar is often hanging or freezing on network interrupts.
Thunar is taking long at startup and with Thunar running my backup drives are never getting to low power sleep mode spinning down...

All these issues seem to be related to some of my bookmarks. After Thunar starts, I see in the logs that all autofs network shares are going to be mounted which is not required until I use the related bookmarks or paths.

Do the bookmarks point to a local or remote location?

As I said, the bookmarks are pointing to nfs and cifs shares.

What are the URIs? If you don't know, check ~/.config/gtk-3.0/bookmarks.

Some of the items:

file:///home/mb/Documents
file:///home/mb/Pictures Pictures
file:///home/mb/mnt/cifs/Department
file:///home/mb/mnt/cifs/Department/Customers/ICH-%20Tech/Projects/007610-01_DE_ICH_Release%206.7

What is the 2nd column here only existing for pictures? Just another bookmark name?

Some of them are symlinked on their way:

# ls -ald /home/mb/mnt
lrwxrwxrwx 1 massimo massimo 4 13. Jan 2015  /home/mb/mnt -> /mnt
ls -ald /home/mb/mnt/cifs
# lrwxrwxrwx 1 root root 11 17. Mär 2020  /home/mb/mnt/cifs -> autofs/cifs

Thunar handles file:// bookmarks like local folders. It will try to open them to obtain additional information (-> triggers automount) and also monitor them for changes. This does not happen for remote locations like smb://localhost/sambashare/folder_inside_sambashare.

Issue #47 (closed) addresses another problem with bookmarks.

This does not happen for remote locations like smb://

Unfortunately, replacing file:// bookmarks with smb:// bookmarks is not a viable option. People mount smb shares onto the filesystem for good reasons.

One reason is command line convenience: typing the path to a nearby directory is far easier than typing whatever annoying path gio is choosing this week.

Another reason is performance: file transfer throughput over Thunar smb bookmarks has historically been (and I think probably still is) terrible compared to a share mounted with mount.cifs.

Even if one were to ignore those particular cases, the fact remains that slow filesystems exist. (Even local disks can be busy or time out.) Thunar should not ever hang; not because such a filesystem is mounted, or for any other reason.

Right. This is basically just a matter of fixing the bookmark handling so that special cases are taken care of.

If handling like a local folder, why does it access all the bookmarks just on startup? I only needs to access them on demand. Then using mounts to remote filesystems this is always a file:// or "local folder", it's the nature of mounts. Detecting the type of a mount is trivial and should be done by Thunar at least if it occasionally tries to access those. This kind of issue happend to other software as well like KDE Kate, that was heavily accessing temporary files and was going to avoid that if the filesystem is remote. Using smb:// would mean Thunar is acting as smb client and creating some temporary internal mount. This would mean I need to tell Thunar or the gvfs all credentials and options for the remote shares, which is done better by system tools like autofs or systemd's automounter. At finally there will always be specific mount types that are not supported or less maintained by Thunar/gvfs such as sshfs or davfs2... Ok, as for gvfs that might be well maintained, but as I need the mounts anyway outside of Thunar and Gtk, I prefer system mounts.

Do you agree there could be a solution for this issue?

If handling like a local folder, why does it access all the bookmarks just on startup?

That is how the current code handles bookmarks. It differentiates between local (file://) and remote (smb://, ftp://, etc.) locations. Local ones are monitored/accessed, remote ones are not.

Note that, I am just pointing out how things work right now. It is clear that the bookmark handling needs to be fixed, and patches are certainly welcome!

What is the reason for monitoring bookmarks without accessing? I don't mind disabling that completely, or making that an option.

As I said before, "to obtain additional information". By trying to open the folder Thunar can check if the location still exists (#47 (closed)). Also, it can determine which custom icon and emblems should be shown.

This can be easily disabled in the code.

As @lastonestanding said, just skip the upper part of the if, and loading should be skipped (dont_load_shortcuts.diff)

Please take a try for the attached diff and let us know if it fixes your problem.

Note that this cant be considered a general fix, since e.g. for Pictures/Documents/Downloads, no special-icons will be used any more. As well bookmarked hidden folders wont be shown as hidden any more and files will not show any emblems.

As discussed with @lastonestanding, it should be possible to get the correct icon for a file only from it's path, without loading it. The emblem-problem is not crucial and can be postponed.

A proper patch which fixes the icon-problem would be very welcome!

(Bug added to roadmap, though not sure if it will be fixed for 4.16)

added 1. Performance label

added 5. Bookmarks label

mentioned in issue #124 (closed)

I confirm this also causes Thunar to (randomly) freeze after waking up from suspend when an NFS mount is in the bookmark, where a reboot can temporarily "fix" it.

Good to know it's been added to roadmap, thanks!

changed milestone to %Xfce 4.18

mentioned in issue #513 (closed)

Hi all. Yes, thunar watches the files that are bookmarked, but thunar is not the problem here. Nemo also watches bookmarks and i think nautilus too. You are using automount and by definition this gives up control over the mounting process. Automount waits for user access on configured directories and then mounts them in. I strongly suggest not to use automount. I will give you my mount script and you will be good to go. I am using thunar with it and i am experiencing absolutely no problems.

The whole script You can find the short version below local-nfs-mount-toggle.sh

What does this script do? I use it on my notebook. If I connect to my home network, the script mounts in my nfs share and links the configured directories to the directories on the share with the same name. If I am not connected to my home network it links the configured directories to the local directories with the same name. In thunar I have bookmarks for every configured directory. So the bookmarks either point to the local version or the shared version of directories.

The script is invoked by a network connection manager (i use wicd on xfce). In wicd it should be located in /etc/wicd/scripts/postconnect and /etc/wicd/scripts/predisconnect. If you are using NetworkManager https://wiki.ubuntuusers.de/NetworkManager/Dispatcher/ then it should be copied to /etc/NetworkManager/dispatcher.d/ . The script works like a toggle. If the share is already mounted and the script is invoked a second time then the script tries to unmount the share.

The short version

It just mounts the share if you are connected to the given ip. I use the same path on my nfs export and local mount point (remoteDirBase). Keep in mind, that the mount parameters I use are a bit dangerous. I use a soft mount (rw,soft,bg,intr,retrans=3,timeo=20). This way nfs does not hang your whole system if the connection goes down, but you could get corrupt data if you are writing to the nfs share while losing connection. Never happened to me though. You can use hard,intr which is recommended. Furthermore i use lazy and force unmount (umount -lf "

remoteDirBase") and then I restart the (eval "

nfsRestartCommand") nfs client. It is another way of not getting any delays. A long time ago I experienced really long delays with systemd, that is why I came up with this approach.

#!/bin/bash
remoteDirBase="/media/nfs/share"                                                 
nfsRestartCommand="service nfs-common restart"                                   
ip="ipoderdomain"

logger "Home Detector Script Invoked"                                                                                 
mount | grep "$remoteDirBase"                                                    
if [ $? -eq 0 ]; then                                                            
    logger "NFS share is mounted"                                                       
    logger "Try to unmount"                                                      
    umount -lf "$remoteDirBase"                                                  
    if [ $? -ne 0 ]; then                                                        
        logger -s "Failed to unmount"                                            
    fi                                                                           
    eval "$nfsRestartCommand"                                                    
else
   logger "NFS share not mounted"                                                                                    
    ping -q -c1 $ip > /dev/null                                                  
    if [ $? -eq 0 ]; then                                                        
        logger "Home Network online"                                             
        mkdir -p "$remoteDirBase"                                                
        logger "Try to mount"                                                    
        mount -t nfs -o rw,soft,bg,intr,retrans=3,timeo=20 $ip:"$remoteDirBase" "$remoteDirBase"
        if [ $? -eq 0 ]; then                                                    
            logger -s "Mounting shared repository successful"                    
        fi
    else                                                                         
        logger "Home Network offline"                                                      
    fi                                                                           
fi

For the record, this problem is not limited to people using automount. It occurs on already-mounted filesystems if the network or file server or local disk become slow or unresponsive.

Seems like Thunar's GUI blocks on I/O, which a GUI should never do. Edited by Forest just now

As I said, I do not experience this problem. I can pull out my network cable while thunar shows a shared device and i get no delays in thunar. Can you go into detail? What are your mount options? By default NFS hangs all your share accessing applications, if it experience problems, because it tries to keep your data intact (hard mount). Use my mount options (soft mount) and the delays are gone.

I don't agree at all with this approach. Mounting shares when necessary is the straight forward way to do. That mounting takes a while for network shares it's in her nature. What you are doing is, you always keep mounts mounted, and if the network is not available, you fake it with local filesystems. And this just because Thunar is touching a lot of resources it does not really need? This leads to other issue for you, what if your network connection breaks? Then your Thunar will freeze for quite a while. Therefore I used to have autofs with short timeouts of about some minutes for unreliable resources such as (known) USB devices and network shares (cifs, nfs, and also davfs2). Reliable devices like SATA I always keep mounted.

This leads to other issue for you, what if your network connection breaks? Then your Thunar will freeze for quite a while.

Please try to read my post above. My thunar does not hang even if I pull out my network cable. My mount and unmount options make it possible. Try them in your autofs config. Or just use my script.

That mounting takes a while for network shares it's in her nature.

My mounts are mounted instantly. Just use my mount options.

Mounting shares when necessary is the straight forward way to do.

No, It is the lazy way to do it, cause you just need to install autofs, copy a sample config from the internet, tweak it a little bit and then it works. You do not have to go into the details of your system and you do not have to write a script. That's fine with me. I did it this way a long time ago and it worked. But it came the day, I experienced the same problems like you have now. So now it is time to adapt and go to the next level, or stay with your autofs and live with the problem.

You mean, if not using your script I could also solve my issue by using your mount options in the autofs config? You are using

rw,soft,bg,intr,retrans=3,timeo=20

Checking my current nfs mount options I have:

rw,vers=3,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=***.***.***.***,mountvers=3,mountport=33704,mountproto=tcp,local_lock=none,addr=***.***.***.***

The only explicit options that I have set are:

-fstype=nfs,rw,async,tcp,soft

About your options:

soft: Improving responsiveness but kind of risky for data integrity.

bg: This one could actually help on the issue as the mount command is not blocking but immediately returning with a zero exit code, letting the fork trying to mount.

intr: Ignored since 2.6.25

retrans: 3 is already default for udp, 2 for tcp. Are you using tcp or udp?

Finally I guess only bg can improve the mount responsiveness. And then I would need to evaluate all the same on cifs, which has no bg option.

Maybe these options help. I can not tell. I do not use an automounter anymore. What I do know is, from the point on I switched from auto mounting to script based mounting, I never had any problems with my nfs shares. I can use any file explorer (thunar, nemo, nautilus ...) and i can pull the network cable and nothing is hanging. The soft option does help here. But as you mentioned it is a bit dangerous.

If I am not mistaken, this issue got fixed together with #513 (closed)

I did some testing with bookmarks pointing to non-available nfs locations and did not get it to hang. Though I did not find a clear reproducer among all the comments here and in the linked forum thread. So if I just failed to reproduce the bug using thunar master (or thunar4.17.7), please reopen and attach a proper, minimal step-by-step reproducer !

closed

Thunar hangs on startup when unavailable network shares are in bookmarks

Submitted by Luca Steinke

Description

-- Subject: Unit mnt-server-data.mount has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- Unit mnt-server-data.mount has failed.

systemd automounts

Designs

Child items ...

Activity