thunar.xml overwritten on first login..

tb0ne24 · 2024-10-12 06:07:18

Hello everyone! o)

I still try to make xfce4 work for me, which includes sensible defaults for a handful applications when creating new user accounts. Getting XFCE / Thunar to just load and not alter the file ~./config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml on first login is where I am stuck right now.

I have the default thunar.xml I want for all new users in: /etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml. This file will be copied to /home/NEWUSER/config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml via the regular adduser script when running "sudo adduser NEWUSER" e.g..

On first login with NEWUSER however, the thunar.xml file of NEWUSER is reset or overwritten with some other default thunar.xml.

If I logout NEWUSER and manually copy
/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml
to
/home/NEWUSER/config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml
once more and relogin with NEWUSER, the customized thunar.xml keeps its content and stays in place as expected.

Questions:
- What magic first-logon-script is running when a user logs on the first time? Does somebody know? o)
- Can I fake that a user already logged on by placing a file somewhere, or would this screw up other things in the longer run?

Thank you in advance! o)

Added later 13 min 30 s:
Some additional context:

All other files in /home/NEWUSER/config/xfce4/xfconf/xfce-perchannel-xml/.. are not changed upon first logon.
I have custom actions and bookmarks e.g., which don't need an additional copy after the first logon.

I'm using a quite basic Debian12 xfce setup.

ToZ · 2024-10-12 09:23:30

That should work.

Do you by chance have a thunar.xml file in /etc/xdg/xfce4/xfconf/xfce-perchannel-xml?
What are the permissions of the file in /etc/skel?
Anything logged to ~/.xsession-errors on first new user log in?

tb0ne24 · 2024-10-12 10:27:51

Hi ToZ! o)

Yes, there is a 89byte file in /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/thunar.xml, it looks like this:
I removed 3 "locked" properties recently from this file, because I was not able to even change sort order anymore.
Not sure how these locked properties got in there, but it's basically "empty" now, no defaults of any kind, no locked properties either.
This is not the file I end up with for NEWUSER.

<?xml version="1.0" encoding="UTF-8"?>
<channel name="thunar" version="1.0">
</channel>

[148930] root@debian 12:07:39 [/etc/xdg/xfce4/xfconf/xfce-perchannel-xml] rc:0 
> ll thunar.xml
-rw-r--r-- 1 root root 89 20241007 14:18 thunar.xml

Permissions and file size in /etc/skel/..

[147138] root@debian 12:00:46 [/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml] rc:0 
> ll thunar.xml 
-rw-r--r-- 1 root op 3.7K 20241012 06:28 thunar.xml

Permissions and file size for NEWUSER after adduser script ran (but before first login)..
All fine up to this point! Expected file size (correct thunar.xml file) and permissions.

[147305] root@debian 12:01:37 [/home/op109/.config/xfce4/xfconf/xfce-perchannel-xml] rc:0 
> ll thunar.xml
-rw-r--r-- 1 op109 op109 3.7K 20241012 11:51 thunar.xml

Permissions and file size for NEWUSER after first login..
Problem, file thunar.xml was replaced / rewritten with some defaults.. o(

[148387] op109@debian 12:03:51 [/home/op109/.config/xfce4/xfconf/xfce-perchannel-xml] rc:0 
> ll thunar.xml
-rw-r--r-- 1 op109 op109 1012 20241012 12:03 thunar.xml

There is nothing of greater concern in ~/.xsession-errors as far as I can see, maybe the last line is interesting?
I wonder why there are references to xubuntu and snapd in there though, never used these before.

Xsession: X session started for op109 at Sat Oct 12 12:03:04 PM CEST 2024
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1026/bus
dbus-update-activation-environment: setting DISPLAY=:11.0
localuser:op109 being added to access control list
dbus-update-activation-environment: setting XDG_DATA_DIRS=/usr/share/xfce4:/usr/share/xfce4:/usr/share/xubuntu:/usr/share/gnome:/usr/local/share:/usr/share:/var/lib/snapd/desktop
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting USER=op109
dbus-update-activation-environment: setting XDG_SESSION_TYPE=x11
dbus-update-activation-environment: setting HOME=/home/op109
dbus-update-activation-environment: setting XRDP_PULSE_SINK_SOCKET=xrdp_chansrv_audio_out_socket_11
dbus-update-activation-environment: setting XRDP_PULSE_SOURCE_SOCKET=xrdp_chansrv_audio_in_socket_11
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1026/bus
dbus-update-activation-environment: setting PULSE_SCRIPT=/etc/xrdp/pulse/default.pa
dbus-update-activation-environment: setting LOGNAME=op109
dbus-update-activation-environment: setting XDG_SESSION_CLASS=user
dbus-update-activation-environment: setting GTK_OVERLAY_SCROLLING=0
dbus-update-activation-environment: setting PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
dbus-update-activation-environment: setting GTK3_MODULES=xapp-gtk3-module
dbus-update-activation-environment: setting XRDP_SOCKET_PATH=/run/xrdp/sockdir
dbus-update-activation-environment: setting XDG_RUNTIME_DIR=/run/user/1026
dbus-update-activation-environment: setting DISPLAY=:11.0
dbus-update-activation-environment: setting LANG=en_US.UTF-8
dbus-update-activation-environment: setting XDG_CURRENT_DESKTOP=XFCE
dbus-update-activation-environment: setting UID=1026
dbus-update-activation-environment: setting SHELL=/bin/bash
dbus-update-activation-environment: setting GDMSESSION=xubuntu
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting XRDP_SESSION=1
dbus-update-activation-environment: setting GPG_AGENT_INFO=/run/user/1026/gnupg/S.gpg-agent:0:1
dbus-update-activation-environment: setting PWD=/home/op109
dbus-update-activation-environment: setting XDG_DATA_DIRS=/usr/share/xfce4:/usr/share/xfce4:/usr/share/xubuntu:/usr/share/gnome:/usr/local/share:/usr/share:/var/lib/snapd/desktop
/usr/bin/x-session-manager: X server already running on display :11.0
/home/op109/Downloads was removed, reassigning DOWNLOAD to homedir
/usr/bin/iceauth:  creating new authority file /run/user/1026/ICEauthority
xfce4-session-Message: 12:03:05.441: SSH authentication agent is already running
gpg-agent: a gpg-agent is already running - not starting a new one

(xfwm4:147696): xfwm4-WARNING **: 12:03:05.966: Unsupported GL renderer (llvmpipe (LLVM 15.0.6, 256 bits)).

24
- pulseaudio xrdp-sink loaded
- pulseaudio xrdp-sink set as default
26
- pulseaudio xrdp-source loaded
- pulseaudio xrdp-source set as default

** (wrapper-2.0:147797): WARNING **: 12:03:07.723: Binding 'XF86AudioLowerVolume' failed!

(wrapper-2.0:147797): pulseaudio-plugin-WARNING **: 12:03:07.729: Could not have grabbed volume control keys. Is another volume control application (xfce4-volumed) running?

** (wrapper-2.0:147797): WARNING **: 12:03:07.740: Binding 'XF86AudioPlay' failed!

(wrapper-2.0:147797): pulseaudio-plugin-WARNING **: 12:03:07.740: Could not have grabbed multimedia control keys.

** (xfdesktop:147727): WARNING **: 12:03:08.452: Failed to register the newly set background with AccountsService '/usr/share/backgrounds/1141401.jpg': GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No such interface “org.freedesktop.DisplayManager.AccountsService”

I sit here with all my hair pulled out! o) Maybe you have another idea?!
One thing I forgot to mention, any user logon always happens via xrdp, but should not matter I think?!

Thank you! o)

Last edited by tb0ne24 (2024-10-12 10:41:28)

ToZ · 2024-10-12 10:44:20

First, try to delete the thunar.xml file in the /etc/xdg path, it shouldn't be there. Perhaps it is being processed and then the /etc/skel file is copied over.

One thing I forgot to mention, the first user logon happens via xrdp, but should not matter I think?

xrdp does affect some stuff - not sure it will here. Try deleting the file above to see if that helps.

tb0ne24 · 2024-10-12 22:13:24

Unfortunately, deleting /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/thunar.xml does not have any positive effect.

My assumption is, that some kind of service/daemon like gsettings, xfconf, xfsettingsd, dconf or the Thunar executable itself is responsible for the unexpected behaviour. I tried to read a lot on Arch-Wiki and the XFCE docs, but there is no exact information on where Thunar is getting its defaults from.

I also looked into the Thunar source code, there is no "thunar.xml" String in there anywhere, so it all seems communication over some service. Unfortunately I didn't get how and when XFCE or Thunar reads settings from what location or service yet, there are a lot of things running which could play a role.

accounts-daemon.service
dbus-daemon (dbus.service?!)
at-spi-bus-launcher
at-spi2-registryd
dconf-service
systemd --user (systemd-user-sessions.service?!)
xfce4-session
xfsettingsd

1) Does xfconf-query for example, gets "Thunar" channel settings from ../xfce-perchannel-xml/thunar.xml over xfsettingsd?
2) Are the files in ~/.config/xfce4/xfconf/xfce-perchannel-xml/.. the source of what can be edited in "Settings Editor" or are they just "dumps" of another hidden database? Like there seems to be for dconf e.g., which is used by Mousepad for some reason.
3) Is there a way to make xfsettingsd (or something else) reload these XML files from filesystem if they are the actual source? I did not find a matching option on xfsettingd at least.

Another detail I missed to mention, I am using a nightly / dev version compiled some months ago. I also have some issues running Thunar in "root" mode with pkexec (which seems to be how to do it in 2024). Also using the "admin://<path>" protocol just give a permission error.

Perhaps my system is "off" in general, hard to tell, I installed "all" packages required manually to not end up bloated (trying to build a very tiny but functional Debian). That said, I have almost all the software running, from Blender to OBS, so it cannot be that bad of a setup.

So, reinstall and test against "official" or do you have another trick up your sleeve? o)

Thank you again, I appreciate your help!

Added later 3 h 57 min 48 s:
I think I found my problem.. let me investigate some more, I will post the details.

Added later 11 h 29 min 39 s:
Hi Toz! o)

Ok, so in the end, it was a syntax error in the thunar.xml file, which the xfconfd daemon does not like. xfconfd then replaces the whole thunar.xml with a minimal variant of thunar.xml it takes from [I don't know where].

The syntax error in thunar.xml for any new user was caused by my adduser.local script, which replaces all occurrences of "/home/olduser" with "/home/newuser" in copies of all the configuration files located in /etc/skel/.config. My addadduser.local script worked fine up until now, but the regular expression used to do the find/replace with the sed command, was not sophisticated enough to not mess up syntax of configuration files in all cases.

So it's my fault in the first place I guess! Yes yes! o)

I still blame Linux applications for not simply putting "$HOME/.config/some-app" in their configuration files and resolving this variable whenever the application is referencing its own configuration location and files. That way I would not have to screw around and try to replace obsolete paths everywhere when duplicating a user profile and it would make configuration files portable by default between systems and user accounts.

Would you or anybody else agree? o)
Can we add that to some POSIX, XDG guideline somewhere?
Write a mail to Mr. Torvalds even? o)

Thank you ToZ for taking the time, your response helped to keep me going.
Have a nice weekend! o)

ToZ · 2024-10-13 18:31:20

Glad you found the issue. I'm going to leave some of my answers here in case it helps to understand how xfconfd and xfce configuration settings are managed.

tb0ne24 wrote:

I tried to read a lot on Arch-Wiki and the XFCE docs, but there is no exact information on where Thunar is getting its defaults from.

https://gitlab.xfce.org/xfce/thunar/-/b … heads#L195

I also looked into the Thunar source code, there is no "thunar.xml" String in there anywhere, so it all seems communication over some service.

Its done through xfconf (https://gitlab.xfce.org/xfce/thunar/-/b … eads#L1408).

Unfortunately I didn't get how and when XFCE or Thunar reads settings from what location or service yet, there are a lot of things running which could play a role.

xfconfd is a onfiguration daemon that runs on Xfce. Most applications (if not all) have now migrated to xfconf. The daemon runs in memory tracking configuration changes and occasionally writes them to the xml files (this is why you shouldn't directly write to these files if you are logged in and the daemon is running). Thunar connects to the xfconf daemon and manages its configuration settings, xfconfd manages the writing, retrieving, and tracking of these settings.

1) Does xfconf-query for example, gets "Thunar" channel settings from ../xfce-perchannel-xml/thunar.xml over xfsettingsd?

It gets it from the xfconfd memory store. xfconfd will write to disk occassionally. xfsettingsd not involved here.

2) Are the files in ~/.config/xfce4/xfconf/xfce-perchannel-xml/.. the source of what can be edited in "Settings Editor" or are they just "dumps" of another hidden database? Like there seems to be for dconf e.g., which is used by Mousepad for some reason.

The settings editor also connects directly to xfconfd and memory storage. Mousepad uses gsettings as it always has - was a little different that way. Recently, a build option was included in Xfce to manages all settings using gsettings instead of xfconfd - but this needs to be enabled at build time.

3) Is there a way to make xfsettingsd (or something else) reload these XML files from filesystem if they are the actual source? I did not find a matching option on xfsettingd at least.

xfsettingsd is not involved here. You can use xfconf-query to directly manipulate the xfconfd settings in memory - in fact this might be an option for you. Create a script that runs at login and use xfconf-query to push the configuration changes you want to make.

tb0ne24 · 2024-10-13 20:30:10

So, I think what happened was the following:
xfconfd tried to read my thunar.xml with syntax error in there, it failed, leaving the memory store of xfconfd empty for that "channel" (I guess).
Thunar then starts and tries to load its settings via xfconfd, it does not find any, so it pushes some defaults to xfconfd, which writes the "unexpected" small thunar.xml over the already existing thunar.xml file, which xfconfd could not load before due to the syntax error.
Would you agree?

Most applications (if not all) have now migrated to xfconf.

Recently, a build option was included in Xfce to manages all settings using gsettings instead of xfconfd - but this needs to be enabled at build time.

Hu? But why? o)
Why all applications migrate to xfconfd, to then have the other settings manager as an option?

You can use xfconf-query to directly manipulate the xfconfd settings in memory - in fact this might be an option for you. Create a script that runs at login and use xfconf-query to push the configuration changes you want to make.

Yeah, I was thinking of something like that as well (before I discovered my bug), but that would have required me to parse existing thunar.xml and push individual settings later on, not really a handsome solution, but fortunately, I don't have to do this. o)
I used xfconf-query before when playing around. Now that you mention it, I remember that it is also capable of setting values, which the name did not imply anymore for me, or does it? I mean "query" is like "fetch" or "get" in my world, but I'm not a native english speaker.

I had come up with a "run_once.desktop" file in .config/autostart to kill xfconfd and thunar, put my thunar.xml there and restart the processes upon first user login. It was working "kind of", as this was the moment I was seeing xfconfd moaning about the malformed xml file. In a more regular situation, where can I see xfconfd logging / debugging information the next time?

Thx! o)

ToZ · 2024-10-14 03:34:10

tb0ne24 wrote:

So, I think what happened was the following:
xfconfd tried to read my thunar.xml with syntax error in there, it failed, leaving the memory store of xfconfd empty for that "channel" (I guess).
Thunar then starts and tries to load its settings via xfconfd, it does not find any, so it pushes some defaults to xfconfd, which writes the "unexpected" small thunar.xml over the already existing thunar.xml file, which xfconfd could not load before due to the syntax error.
Would you agree?

Yes, this sounds like a feasible explanation.

Recently, a build option was included in Xfce to manages all settings using gsettings instead of xfconfd - but this needs to be enabled at build time.
Hu? But why? o)
Why all applications migrate to xfconfd, to then have the other settings manager as an option?

I think I may have mis-understood this patch. On closer review, it looks like it allows xfconf to also manage those apps (e.g. mousepad) that use gsettings.

You can use xfconf-query to directly manipulate the xfconfd settings in memory - in fact this might be an option for you. Create a script that runs at login and use xfconf-query to push the configuration changes you want to make.
Yeah, I was thinking of something like that as well (before I discovered my bug), but that would have required me to parse existing thunar.xml and push individual settings later on, not really a handsome solution, but fortunately, I don't have to do this. o)
I used xfconf-query before when playing around. Now that you mention it, I remember that it is also capable of setting values, which the name did not imply anymore for me, or does it? I mean "query" is like "fetch" or "get" in my world, but I'm not a native english speaker.

Yes it can get and set configuration settings on the fly. More information at this link.

I had come up with a "run_once.desktop" file in .config/autostart to kill xfconfd and thunar, put my thunar.xml there and restart the processes upon first user login. It was working "kind of", as this was the moment I was seeing xfconfd moaning about the malformed xml file. In a more regular situation, where can I see xfconfd logging / debugging information the next time?

I'm not sure it does. You could look at ~/.xession-errors.log or your systemd user journal to see if anything is output. Otherwise, you might need to build it from source with debug=yes as a build parameter (would need to check).

Xfce Forum

Sub domains

#1 2024-10-12 06:07:18

thunar.xml overwritten on first login..

#2 2024-10-12 09:23:30

Re: thunar.xml overwritten on first login..

#3 2024-10-12 10:27:51

Re: thunar.xml overwritten on first login..

#4 2024-10-12 10:44:20

Re: thunar.xml overwritten on first login..

#5 2024-10-12 22:13:24

Re: thunar.xml overwritten on first login..

#6 2024-10-13 18:31:20

Re: thunar.xml overwritten on first login..

#7 2024-10-13 20:30:10

Re: thunar.xml overwritten on first login..

#8 2024-10-14 03:34:10

Re: thunar.xml overwritten on first login..

Board footer