Major correction: downgrading to 1.8.1.11.gf5147445-1 does fix issue. Needed to restart xfce4 session first.

After downgrade, thunar opened normally. Upgraded back to 1.8.2-1 and it continued to work. Did reboot, still continued to work. No other packages were upgraded in the interim. Leaving open for now in case anyone else encounters.

I have the same issue and can confirm that downgrading to '1.8.1.11.gf5147445-1' does fix it.
But updating back to 1.8.2-1 and rebooting breaks it again.

Interesting. Found a lot of references to other applications (gedit, gnome-control-center, baobab and others) in the past that showed the same message. But nothing for thunar, and nothing in the Arch Forums.
Looks like applications fail to start and get stuck in an unterminated state.

Not sure why a reboot doesn't clear that state.

Same issue here, downgrading to 1.8.1.11.gf5147445-1 fixed it.

If I run sudo /usr/bin/thunar
I get the error message:
Thunar: Failed to initialize Xfconfig: Server address of type unix was missing argument path ...
But it runs.
If I run without sudo nothing seems to happen.

I also get the error "Failed to register: Timeout was reached" when starting thunar as a user. But it does start as root (and also using sudo).

This is on a virtual machine on a Win7 host. My native PC installation of Arch doesn't have this issue. Not sure if that's relevant.

I confirm the issue with Thunar 1.8.2

I get this error when I run thunar as one user but it works well when I run it as another.
Downgrading didn't help me.

I am also experiencing this timeout was reached issue and can confirm that on my system thunar can also still be executed using sudo privileges, with the same output as @bgroves. I have not yet tried downgrading to a previous version as I have an alternate to utilise in the meantime.

I'm unable to reproduce the issue under i3, as a regular user. I'm running /usr/bin/thunar, and everything seems to work.

Which windowmanager are people running when Thunar fails to run?

Does it work if ~/.config/Thunar is temporarily renamed?

@xyproto

1. I'm using xfce4 with xfwm4.

2. No, renaming the Thunar folder in ~/.config doesn't change anything. It doesn't even create a new default instance of the folder upon executing. (I'm assuming as an outsider that this would normally be the case). For the record I did not restart xfce after moving the folder.

I experienced the same issue under i3 after update.Thunar worked with sudo.
Tried to remove .config/Thunar, without any result.
After the command
killall thunar
Thunar worked again, but I needed to do it after a reboot (maybe also after a simple logout because of the following).
Commenting out from configuration of i3 the following line
exec --no-startup-id thunar --daemon &
Thunar is now correctly working and also when starting i3 Thunar starts without problem
(it starts because of the line
exec --no-startup-id thunar
still present in the configuration file of i3)
I suppose that the problem is in the early launch of Thunar as a daemon done by the wm in use to speed up following launches of Thunar.
Hope that this will help!

I also managed to retrieve functionality through $ killall Thunar #I found it to be case sensitive

At present I can't comment on reboot behaviour. Thanks to @aghu

I was able to fix this permanently without downgrading to 1.8.1.11.gf5147445-1 by deleting the file ~/.cache/sessions/xfce4-session-<hostname>:0

I can second deleting ~/.cache/sessions/xfce4-session-<hostname>:0 as a fix.

So far Thunar 1.8.2-1 is now working for me, even after reboot.

I am having this problem at random: sometimes Thunar starts, sometimes it doesnt.

Updated System with thunar 1.8.4-2 (xfce4) [installed]

Terminal Response: "Failed to register: Timeout was reached"

Is there any update on this?

Since some time i have this during a xfce session (initially fine, after some time thunar couldnt be opened any longer).
When this happens thunar couldnt be restarted (killall thunar not working - no thunar process)
Maybe related to gvfs-udisks2 - but just an asumption (found some things about this)
Volume Management inside thunar is switched off (thunar-volman and thunar-volman-settings can still be opened)
NFS or SMB connections are fine too (when using a terminal everything can be reached)

I'm getting the same as Thomas and I've traced it back to the thunar-1.8.11-1 update back in November.
I have to reboot every couple days to get Thunar working again
I can run Thunar as root no issues but as my normal user I get :
$ thunar
Failed to register: Timeout was reached

and also seeing in the logs:
Failed to set property "thunar::/last-details-view-column-widths": Operation was cancelled

Have tried various cures like clearing out ~/.cache/sessions/ and other tweaks all have had no impact.

I remove thunar and compile latest version Thunar-1.8.12 from source. Also this version not start with default user.
> Failed to register: Timeout was reached
Only running with superuser $ sudo thunar will open it.
But after reboot new installed thunar open will current user.

I get the same error in version 1.8.14-1. Deleting the xfce4 session files doesn't help.

sudo thunar works.

Same error here with 1.8.15-1 after thunar crashed.

Can't reproduce the issue on latest update (.16);
please be sure it's not a .config problem: for safety, you can test it creating a new user; in this way you are sure configuration files are not broken.

FWIW, I have been able to (somewhat) reliably reproduce this error when real RAM is maxed out and a system is heavily into swap.

same issue happened to me, fresh ubuntu 20.04
sudo thunar - works

[but my thunar version is: thunar 1.8.14 (Xfce 4.14)]

I occasionally have similar problems after system is running for a while. Thunar or any window for file management, like "Attach files" in Thunderbird fails to open. After some stracing it seemed it was stuck on dbus/gvfs, and sure enough, after running "systemctl --user restart gvfs-daemon.service" Thunar opened instantly. I have a lot of network filesystems mounted (autofs, sshfs, etc) and I suspect gvfs is stuck on stale network mount.