Nextcloud client starts with Nautilus automatically

[patzm]

Expected behaviour

A user account doesn't use Nextcloud. Hence, I don't expect to ever see the client (get started).

Actual behaviour

When I start nautilus (Files), the nextcloud client gets started as well and I see the setup window.

Steps to reproduce

1. install Nextcloud 3.0.2
2. install Nautilus 3.38.1-8ed4a28f2
3. make sure that "Launch on System Startup" is un-checked
   
4. start nautilus (Files) and see the Nextcloud setup screen pop up:
   

Client configuration

Client version: 3.0.2 (Manjaro)
Operating system: Manjaro, Linux Kernel 5.8.18-1-MANJARO
OS language: English
Qt version used by client package (Linux only, see also Settings dialog): isn't shown there. I think 5.8
Client package (From Nextcloud or distro) (Linux only): local/nextcloud-client 3.0.2-1
Installation path of client:

Further information:

• system has two users, only one uses Nextcloud. The other doesn't use it but still sees the client get started (see actual behavior)
• both users use the i3 window manager. Gnome is also installed.
• this behavior only started a few weeks ago (either a nautilus or Nextcloud update might have triggered that?)

Server configuration

Nextcloud version: Nextcloud 18.0.3
Storage backend (external storage): file system mounted through docker, see https://github.com/patzm/dockerfiles/blob/6bd6bdefdf7f11d21ff1c46b913f2cf84d655d28/nextcloud/docker-compose.yml

Logs

1. Client logfile:

2020-11-10 08:38:16:174 [ info nextcloud.gui.application ]:	"################## Nextcloud locale:[en_US] ui_lang:[en_US] version:[3.0.2git] os:[Manjaro Linux]"
2020-11-10 08:38:16:175 [ info nextcloud.gui.application ]:	Running for 4214.24 sec
2020-11-10 08:38:16:175 [ debug nextcloud.gui.systray ]	[ OCC::Systray::computeWindowReferencePoint ]:	screenRect: QRect(0,0 1920x1080)
2020-11-10 08:38:16:175 [ debug nextcloud.gui.systray ]	[ OCC::Systray::computeWindowReferencePoint ]:	taskbarRect: QRect(0,0 1920x32)
2020-11-10 08:38:16:175 [ debug nextcloud.gui.systray ]	[ OCC::Systray::computeWindowReferencePoint ]:	taskbarScreenEdge: OCC::Systray::TaskBarPosition::Bottom
2020-11-10 08:38:16:175 [ debug nextcloud.gui.systray ]	[ OCC::Systray::computeWindowReferencePoint ]:	trayIconCenter: QPoint(1085,580)
2020-11-10 08:38:16:176 [ debug nextcloud.gui.systray ]	[ OCC::Systray::computeWindowPosition ]:	taskbarScreenEdge: OCC::Systray::TaskBarPosition::Bottom
2020-11-10 08:38:16:176 [ debug nextcloud.gui.systray ]	[ OCC::Systray::computeWindowPosition ]:	screenRect: QRect(0,0 1920x1080)
2020-11-10 08:38:16:176 [ debug nextcloud.gui.systray ]	[ OCC::Systray::computeWindowPosition ]:	windowRect (reference) QRect(885,533 401x511)
2020-11-10 08:38:16:176 [ debug nextcloud.gui.systray ]	[ OCC::Systray::computeWindowPosition ]:	windowRect (adjusted ) QRect(885,533 401x511)
2020-11-10 08:38:48:359 [ info nextcloud.gui.account.manager ]:	Saved all account settings, status: QSettings::NoError
2020-11-10 08:38:48:373 [ debug nextcloud.gui.socketapi ]	[ OCC::SocketApi::~SocketApi ]:	dtor

2. Web server error log: I am pretty sure this is independent of the server. Please request this if you think otherwise.
3. Server logfile: nextcloud log (data/nextcloud.log): I am pretty sure this is independent of the server. Please request this if you think otherwise.

[patzm]

I think this might have gotten triggered by #1729. I tracked it now down to the dbus.service, which starts /usr/share/dbus-1/services/com.nextcloudgmbh.Nextcloud.service. I think this might be globally invoked by the entry /usr/share/cloud-providers/com.nextcloudgmbh.Nextcloud.ini.

Running

systemctl status

Shows me:

[patzm]

Maybe it is also the shell extension: shell_integration/nautilus/syncstate.py
Edit: probably not. I moved syncstate-Nextcloud.py out of this folder and the nextcloud client is still launched.

[patzm]

Ok, nailed it down:
if I insert gibberish into the cloudprovider in /usr/share/cloud-providers/com.nextcloudgmbh.Nextcloud.ini, the client does not start anymore.

Now the question (to @er-vin?): what would be expected?

• Should cloudproviders (gnome?) not invoke the nextcloud service in the first place?
• Should the nextcloud service not start, if no nextcloud account is configured?
• Something entirely different?

[patzm]

Ok, this seems to be a duplicate of #1982, I suggest to continue the discussion over there.

[badshah400]

Sorry for commenting on this old-ish bug report, but it would be helpful for me to get some advice from nextcloud devs about whether it is safe to do the following (I am trying to fix this issue for openSUSE's RPM packages by packaging the libcloudproviders dbus files as an optional package, not installed by default as part of nextcloud-desktop):

1. Build nextcloud with libcloudproviders support, but then not install these two files (for our RPM package, we would simply omit these two files from the default nextcloud-desktop rpm):
   • /usr/share/dbus-1/services/com.nextcloudgmbh.Nextcloud.service
   • /usr/share/cloud-providers/com.nextcloudgmbh.Nextcloud.ini
2. Allow somebody who wants to enable libcloudproviders support to install a new package (let's call it nextcloud-libcloudproviders-support) that simply installs these two files, so that they can start using features from this integration.

I followed issue #1982, but that discussion seems to have side-tracked into whether we can disable file browser integration completely or not, and disabling that is not what we are contemplating doing at all.

Thanks in advance for any suggestion.

[Razer0123]

Still having this issue, it's crazy we can't stop it from autostarting

Are there new updates regarding this?

[Delor3an91]

Hi Everybody,

I've the exact same problem... Is a fix solution available?

Wish You well

[darioseidl]

You can find a fix in this comment (to disable it globally) or in this comment (to disable it for a per user).