[Bug]: Client autostarts even if autostart is disabled

[Razer0123]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

I have disabled Nextcloud autostart in settings, but it keeps autostarting

Steps to reproduce

1. Disable autostart in settings
2. Reboot

Expected behavior

No autostart

Which files are affected by this bug

none

Operating system

Linux

Which version of the operating system you are running.

Fedora 39

Package

Distro package manager

Nextcloud Server version

no idea

Nextcloud Desktop Client version

3.10.0

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Enabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

No response

Additional info

No response

[regulator-g]

occurs with both flatpak and native versions

removing nextcloud-client-nautilus helps but every time nautilus is launched the nextcloud desktop client starts too

opening nemo doesnt start nextcloud though

[topas-rec]

I can confirm that nextcloud client starts when Nautilus is started.
Autostart in nextcloud is disabled.

Properties of the started process are besides other:

---

When Nautilus is closed and nextcloud is quit (Menu - quit, not just closing the window) then starting nautilus again does not have the above mentioned side effect.

[regulator-g]

I think this is happening in KDE plasma/Dolphin too, noticed Nextcloud running when I didn't start it although if I quit it, it doesnt seem to start up again thankfully

[thinkORo]

How can I prevent this automatic start? Since I first have to decrypt an encrypted drive, the autostart is extremely annoying.

Hint: I'm not running on KDE but XFCE4. Therefore it seems like a general "misbehaviour".

[Imberflur]

It seems to be triggered by the cloud providers integration.

@thinkORo
I was able to at least temporarily work around it by commenting out the lines noted in #1982 (comment)

I also found some other discussion around this issue here https://gitlab.gnome.org/World/libcloudproviders/-/issues/17

[ckstevenson]

It seems to be triggered by the cloud providers integration.

@thinkORo I was able to at least temporarily work around it by commenting out the lines noted in #1982 (comment)

I also found some other discussion around this issue here https://gitlab.gnome.org/World/libcloudproviders/-/issues/17

Nice link. This is the same way I experience the issue. I only use nextcloudcmd to sync some data in a script, so it is extremely annoying when I need to upload a file via a gtk application and then the Nextcloud client opens up. I want to say the issue for me started after I switched to the dbus-broker some weeks ago, but I am unsure.

Edit: initial tests show the temporary work around also fixing the issue for me.

[topas-rec]

Happens for me also with the dbus-daemon-units installed instead of dbus-broker-units.

[topas-rec]

@thinkORo
I was able to at least temporarily work around it by commenting out the lines noted in #1982 (comment)

Doesn't work on my machine anymore. If someone has another workaround please let me know, because I uninstalled it.

[thinkORo]

@topas-rec
I can confirm that the workaround doesn't work any longer with a newer version of the nextcloud client.

It is a great pity that a new version has been released without solving this annoying autostart problem.

I currently only use Nextcloud's file sync out of laziness. My thoughts are along the same lines: delete Nextcloud Client and switch to an alternative completely.

BUT: I hope that someone from the nextcloud team looks at this bug and fixes it.

I'll wait a little longer before making my final decision. Fortunately, I have Linux and don't have to reboot my system every day :-)

[dennis2society]

I ran into the same issue on a Manjaro system with KDE Plasma.
First noticed that the "Open File" dialog in VS Code would start the nextcloud-client. I can reliably reproduce the issue with all programs which depend on GTK3/4 which again depends on "libcloudproviders", e.g. Audacity and even Firefox (Ctrl+O) will start the nextcloud-client.

There is a DBUS service registered in /usr/share/dbus-1/services:

[user@computername ~]$ cat /usr/share/dbus-1/services/com.nextcloudgmbh.Nextcloud.service 
[D-BUS Service]
Name=com.nextcloudgmbh.Nextcloud
Exec=/usr/bin/nextcloud --background

This one obviously listens to GTK file dialogs.
I will test what happens if I remove that DBUS service.

Edit: I can confirm that removing this DBUS service prevents the nextcloud-client from autostarting, and so far I have not found any disadvantage. When I start the client manually, all syncing appears to be working fine.

[FelixPehla]

I can confirm that removing this DBUS service prevents the nextcloud-client from autostarting, and so far I have not found any disadvantage. When I start the client manually, all syncing appears to be working fine.

While this will work, the file will likely be recreated whenever you update the corresponding package. A better approach would be masking the service by copying the file to /usr/local/share/dbus-1/services/ and replacing Exec=/usr/bin/nextcloud --background with Exec=/bin/false.

[wookietreiber]

A better approach would be masking the service by copying the file to /usr/local/share/dbus-1/services/ and replacing Exec=/usr/bin/nextcloud --background with Exec=/bin/false.

Note that using /usr/local/share applies to all users. You can mask this just for yourself in $XDG_DATA_HOME/dbus-1/services (XDG_DATA_HOME usually points to ~/.local/share):

# ~/.local/share/dbus-1/services/com.nextcloudgmbh.Nextcloud.service
[D-BUS Service]
Name=com.nextcloudgmbh.Nextcloud
Exec=/usr/bin/false

---

Also, IMO I think of this auto start behavior as a feature not a bug, the software is doing what it's supposed to be doing, i.e. making Nextcloud-based file access (think of it like auto mount) available e.g. when browsing files, and this is supposedly why things like Nautilus trigger it. It's a feature that not everyone wants (me included), but that's fine because you can easily disable it by masking like we've shown above. Unfortunately, the integration via dbus, who triggers it, how to mask it, etc. is not immediately apparent.

[jm355]

It's not a feature-not-a-bug. The bug is that the option in settings to disable autostart doesn't actually disable autostart. If this is the intended behavior, then that setting shouldn't exist

[wookietreiber]

It's not a feature-not-a-bug. The bug is that the option in settings to disable autostart doesn't actually disable autostart. If this is the intended behavior, then that setting shouldn't exist

Autostart (boot, user session, ...) is something different than a triggered start. There is no bug with autostart, what's causing the client to start is a trigger via dbus (that's the feature I was talking about), that may or may not coincidentally occur quickly enough that it seems like autostart.

[jm355]

Oh I see. You're right, the setting is indeed labeled to toggle "Launch on system startup", so you're right that technically, it should have no impact on any other ways it might get launched. So I guess the request is more along the lines of adding an option in settings to mask the nextcloud dbus service instead of having to do it manually