vmware-user-suid-wrapper creates dconf files with root ownership in MATE desktop environment, causing permission denied errors

[con-english]

Describe the bug

When running open-vm-tools on Ubuntu 22.04.3 with MATE desktop environment, the vmware-user process (via vmware-user-suid-wrapper) creates the dconf configuration file /run/user/UID/dconf/user with root ownership instead of user ownership. This causes permission denied errors and prevents MATE desktop components and applications from functioning properly.

Key observations:

• This issue is MATE-specific and does NOT occur in GNOME environments
• The problem occurs when users exit fullscreen mode, disconnect, and reconnect to sessions
• The same version of open-vm-tools works correctly in GNOME, indicating the issue is specific to how the suid wrapper handles privilege dropping in MATE
• Issue has been verified to persist across multiple open-vm-tools versions

Affected Components:

• mate-settings-daemon
• blueman-applet
• mate-power-manager
• Any application relying on dconf

Reproduction steps

1. Install Ubuntu 22.04.3 (Jammy Jellyfish) with MATE desktop environment
2. Install open-vm-tools (tested with versions 2:12.1.5-ubuntu0.22.04.2)
3. Start a VDI session
4. Verify dconf/user file is owned by the user
5. Exit fullscreen mode
6. Disconnect from the VDI session
7. Reconnect to the VDI session
8. Verify dconf/user file ownership again

Expected behavior

The /run/user/UID/dconf/user file should be created and maintained with user ownership (not root), allowing the user's desktop session to properly read and write dconf settings. This behavior should match what is observed in GNOME environments.

Additional context

Environment:

• OS: Ubuntu 22.04.3 (Jammy Jellyfish)
• Desktop Environment: MATE (issue does NOT occur with GNOME)
• open-vm-tools versions tested: 2:12.1.5-3ubuntu0.22.04.2
• Both versions exhibit the same issue

Error Message from the logs:

dconf-CRITICAL **: unable to create file '/run/user/107094/dconf/user': Permission denied. dconf will not work properly.
mate-settings-daemon: dconf-CRITICAL **: unable to create file '/run/user/107094/dconf/user': Permission denied
blueman-applet: dconf-CRITICAL **: unable to create file '/run/user/107094/dconf/user': Permission denied
Gtk-CRITICAL **: Unable to create user data directory '/homes/dovska/.local/share' for storing the recently used files list: Permission denied
PowerManager-ERROR **: Error in dbus - GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Permission denied

Workaround
A wrapper script that explicitly sets user environment variables before calling vmware-user-suid-wrapper resolves the issue, confirming the root cause is in vmware-user-suid-wrapper's environment handling in MATE.

Wrapper Script:
Wrapper Script we set up:
(/usr/local/bin/vmware-user-wrapper):

#!/bin/bash
export HOME="/home/$USER"
export USER="$USER"
export LOGNAME="$USER"
export XDG_RUNTIME_DIR="/run/user/$(id -u)"
exec /usr/bin/vmware-user-suid-wrapper
(Make the script executable: chmod +x /usr/local/bin/vmware-user-wrapper)

The we modified the vmware-user.desktop Entry (/etc/xdg/autostart/vmware-user.desktop):

[Desktop Entry]
Type=Application
Name=VMware User Agent
Exec=/usr/local/bin/vmware-user-wrapper

With this workaround, the issue does not occur in MATE.

[rprabhud]

Hi,
Thanks for reporting this.
I checked in Ubuntu 22.04.3 VM. I did not see any issue of changes in /run/user//dconf/user file ownership.
Is it a problem only when existing fullscreen mode and disconnecting from VDI session?
I tried with VMRC and I did not see any issue.
What VDI solution are you using?
vmware-user-suid-wrapper should be run as root and I did not find anything which is different for GNOME and MATE in the first look at the code.

Which is that log file where you are seeing the dconf error logs?
It says "unable to create file '/run/user/107094/dconf/user'". That means file is not even created?

May be I can try to create an exact setup to reproduce the issue.

Thanks.

[con-english]

This is a customer-reported issue seen in production with Mobileye Vision Technologies Ltd on Horizon VDI (Linux desktop). We asked the customer to test reproduction with VMRC, however, it doesn't happen on VMRC, likely because VMRC connects to the console and not display :100

1) Is it only when exiting fullscreen mode and disconnecting from VDI session?

From the ticket, the reproducible scenario is: exit fullscreen mode → disconnect → reconnect. During disconnect, the /run/user//dconf/user file is deleted. Upon reconnect, it is recreated with root ownership. The ticket also notes the issue can be triggered by resizing the VDI window.

2) What VDI solution are you using?

Omnissa/VMware Horizon (on-prem).

Environment:

Ubuntu 22.04.3 (Jammy)

Horizon Agent 2406 / Horizon 8.13

MATE desktop

3) Which log file shows the dconf errors?

The errors are captured in the Omnissa Horizon agent logs, specifically in DesktopWorker logs from the VDI session diagnostic bundles:

dconf-CRITICAL **: unable to create file '/run/user/<uid>/dconf/user': Permission denied

If you need additional diagnostic captures (journalctl, etc.), we can request those from the customer.

4) "unable to create file … means file is not even created?"

According to the ticket's reproducibility steps: the file is deleted when disconnecting from the VDI session. Upon reconnect, the file is recreated with root ownership. From the desktop components' perspective it shows as "unable to create" because the recreated file is owned by root and not writable by the user.

Reproduction Steps

1. Install Ubuntu 22.04.3 with MATE desktop
2. Install Horizon Agent 2406 / Horizon 8.13
3. Start a Horizon VDI session
4. Verify /run/user/<uid>/dconf/user is owned by user
5. Exit fullscreen or trigger VDI window resize
6. Disconnect the VDI session
7. Reconnect to the session
8. Observe /run/user/<uid>/dconf/user deleted and recreated with root ownership
9. dconf permission errors and loss of settings follow

Expected: dconf runtime file remains user-owned (matches GNOME behavior)
Actual: root ownership appears (MATE + Horizon reconnect)

Confirmed Workaround
Wrapping vmware-user-suid-wrapper with environment variable setup completely resolves the issue:

#!/bin/bash
export HOME="/home/$USER"
export USER="$USER"
export LOGNAME="$USER"
export XDG_RUNTIME_DIR="/run/user/$(id -u)"
exec /usr/bin/vmware-user-suid-wrapper

If you need additional diagnostic data, we can provide logs from the customer environment.

[rprabhud]

Hi again,
Thanks for the additional details. We have opened an internal PR for following up on this.
We will let you know if any additional logs are needed.
Thanks.

[con-english]

Hi,
Are there any updates or feedback you can share please?
Thanks

[rprabhud]

Hi,
This is clearly not a VMTools issue. We had our Display Resolution team check the issue, and according to them, this seems to be a Omnissa Horizon problem. Could you please open an issue with Omnissa Horizon?
Thanks.