#1072382 nextcloud-desktop: Randomly starts, keeps restarting on exit

Package:
nextcloud-desktop
Source:
nextcloud-desktop
Description:
Nextcloud folder synchronization tool
Submitter:
John Doe
Date:
2026-10-05 12:09:02 UTC
Severity:
normal
Tags:
#1072382#5
Date:
2024-06-02 02:02:21 UTC
From:
To:
Dear Maintainer,

The Nextcloud desktop application often seems to start of its own accord, and
frequently restarts when I exit it (by right clicking the tray icon - Exit
Nextcloud).

#1072382#10
Date:
2025-05-21 22:39:41 UTC
From:
To:
Hi,

I have the same issue since updating from bookworm to testing/trixie. If I quit
Nextcloud via the context menu of the tray icon, it re-starts after a few
seconds; same if I use 'nextcloud --quit' on the command line.

Additionally; I've noticed log output like the following in journalctl:

    May 21 22:19:09 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.909' (uid=1000 pid=793971 comm="/usr/bin/firefox-esr")
    May 21 22:19:09 glados com.nextcloudgmbh.Nextcloud[1791706]: Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
    May 21 22:19:09 glados com.nextcloudgmbh.Nextcloud[1791706]: Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
    May 21 22:19:09 glados com.nextcloudgmbh.Nextcloud[1791706]: If this causes problems, reconfigure your locale. See the locale(1) manual
    May 21 22:19:09 glados com.nextcloudgmbh.Nextcloud[1791706]: for more information.
    May 21 22:19:10 glados com.nextcloudgmbh.Nextcloud[1791706]: nextcloud.gui.application: Migrating old config from "/home/rohieb/.local/share/Nextcloud" to "/home/rohieb/.config/Nextcloud"
    May 21 22:19:10 glados com.nextcloudgmbh.Nextcloud[1791706]: nextcloud.gui.application: Failed to move the old config directory to its new location ( "/home/rohieb/.local/share/Nextcloud" to "/home/rohieb/.config/Nextcloud" )
    May 21 22:19:10 glados com.nextcloudgmbh.Nextcloud[1791706]: nextcloud.gui.application: Will move the individual files QList("Nextcloud_sync.log")
    May 21 22:19:10 glados com.nextcloudgmbh.Nextcloud[1791706]: nextcloud.gui.application: Fallback move of  "Nextcloud_sync.log" also failed
    May 21 22:19:10 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Successfully activated service 'com.nextcloudgmbh.Nextcloud'

The command name of the activating DBus service varies:

    $ journalctl --user  --since '5 days ago'  | grep "service name='com.nextcloudgmbh.Nextcloud' requested"
    May 19 21:23:57 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.117' (uid=1000 pid=14506 comm="/usr/libexec/xdg-desktop-portal-gtk")
    May 21 22:19:09 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.909' (uid=1000 pid=793971 comm="/usr/bin/firefox-esr")
    May 21 22:19:13 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.548' (uid=1000 pid=626253 comm="/usr/bin/python3 /usr/bin/variety --next")
    May 21 22:19:26 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.117' (uid=1000 pid=14506 comm="/usr/libexec/xdg-desktop-portal-gtk")
    May 21 22:22:31 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.909' (uid=1000 pid=793971 comm="/usr/bin/firefox-esr")
    May 21 22:24:40 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.117' (uid=1000 pid=14506 comm="/usr/libexec/xdg-desktop-portal-gtk")
    May 21 22:29:51 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.909' (uid=1000 pid=793971 comm="/usr/bin/firefox-esr")
    May 21 22:30:35 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.909' (uid=1000 pid=793971 comm="/usr/bin/firefox-esr")
    May 21 22:32:01 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.909' (uid=1000 pid=793971 comm="/usr/bin/firefox-esr")
    May 21 22:34:27 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.548' (uid=1000 pid=626253 comm="/usr/bin/python3 /usr/bin/variety --next")
    May 21 22:42:18 glados dbus-daemon[1259]: [session uid=1000 pid=1259 pidfd=5] Activating service name='com.nextcloudgmbh.Nextcloud' requested by ':1.909' (uid=1000 pid=793971 comm="/usr/bin/firefox-esr")

I'm not really sure why the DBus service is triggered. Given that all three
apps use GTK, I suspect something about GNOME cloudprovider integration…?

I've removed /usr/share/dbus-1/services/com.nextcloudgmbh.Nextcloud.service for
now, and after rebooting, the problem is no longer present and I can use (and
quit!) nextcloud normally again. (This is more of a workaround than a fix, since
the file will get re-installed again on a package update…)

HTH,

 - Roland

#1072382#15
Date:
2025-06-14 17:29:00 UTC
From:
To:
Hey Roland,

thanks for digging deeper into this issue, that gave me enough information to
search a corresponding upstream bug:

https://github.com/nextcloud/desktop/issues/1982

At least for GNOME desktop it is a known issue, that nextcloud is started
every time you open nautilus or any file picker dialog. Unfortunately the
desktop client has no way to disable it. There is a workaround to override the
dbus service file:

https://github.com/nextcloud/desktop/issues/1982#issuecomment-1008865047

First the issue needs to be fixed within upstream before I can do anything
within Debian.

Regards,

hefee

#1072382#24
Date:
2026-10-05 11:57:16 UTC
From:
To:
I can confirm this bug on Debian 13 (trixie), and I found that it can
have a substantially more serious consequence than merely restarting the
Nextcloud client unexpectedly.

On logout from a GNOME Wayland session, Firefox requested activation of
com.nextcloudgmbh.Nextcloud after the already running Nextcloud instance
had been terminated:

|dbus-daemon: Activating service name='com.nextcloudgmbh.Nextcloud'
requested by ... firefox-esr|

The newly D-Bus-activated Nextcloud process was started while the
graphical session was already being torn down. It consequently failed to
connect to Wayland/X11, but before terminating it requested
org.freedesktop.portal.Desktop.

This raced with gnome-session-restart-dbus.service. systemd then refused
to stop/restart the user D-Bus because xdg-desktop-portal.service had a
start job queued:

|Transaction for dbus.service/stop is destructive
(xdg-desktop-portal.service has 'start' job queued, but 'stop' is
included in transaction).|

gnome-session-ctl consequently reported:

|Failed to restart DBus service:
GDBus.Error:org.freedesktop.systemd1.TransactionIsDestructive|

The following graphical login then inherited the broken user-bus/portal
state. Applications launched after login were delayed until portal/D-Bus
activation timeouts of up to 120 seconds had expired.

I tested the workaround suggested in this bug by overriding the per-user
D-Bus service:

|~/.local/share/dbus-1/services/com.nextcloudgmbh.Nextcloud.service|

with:

|[D-BUS Service] Name=com.nextcloudgmbh.Nextcloud Exec=/bin/false|

After reloading the D-Bus configuration, the same Firefox request still
occurred during logout, but failed immediately with status 1.
gnome-session-restart-dbus was then able to stop the user D-Bus normally
in the same second.

The subsequent login was immediate. Nextcloud was still started normally
by GNOME autostart and could use xdg-desktop-portal successfully.

I repeated the logout/login test and deliberately waited for a Nextcloud
notification before launching applications. They still started
immediately, excluding the Nextcloud notifications themselves as the
cause of the delay.

Thus disabling only the unintended D-Bus activation of Nextcloud
provides a reproducible A/B test for the problem.

Relevant versions:

|Debian 13 (trixie) nextcloud-desktop 3.16.7-1~deb13u1 firefox-esr
140.16.0esr-1~deb13u1 gnome-session-bin 48.0-1+deb13u1
gnome-session-common 48.0-1+deb13u1 dbus-user-session 1.16.2-2 systemd
257.13-1~deb13u1|

I will report the resulting gnome-session D-Bus restart race separately,
since the same race can in principle be triggered by applications other
than Nextcloud.