I can add that to options.rst, but the terse explanation still seems pretty meaningless; at least for me there’s no visible difference when I run nextcloud with --background compared to running without.

This could be due to #2333 though, if running without --background is supposed to open the main dialog (which has never worked on Focal). If so, I’d mention this too, something like: ”Launch the application in the background (without opening the main dialog).”

@FlexW Not really, as I don’t know what the parameter does… due to it being undocumented :) Editing options.rst shouldn’t be an issue, I’d just need to know what it should say about --background.

Preface

Ticking the ”Launch on System Startup” box in the desktop client’s General settings tab (correctly) adds a .desktop file under ~/.config/autostart/, with the following Exec line:

    Exec="/usr/bin/nextcloud" --background

Expected behaviour

The effect of --background should be mentioned in options.rst (and the resulting online documentation).

Actual behaviour

The --background parameter is undocumented.

Client configuration

Client version: 3.2.1
Operating system: Ubuntu 20.04
OS language: English
Client package: 3.2.1-20210429.171749.5901a0f98-1.0~focal1

Nextcloud is somehow different from other apps in this regard, as no other light (white) apps on the same device have this issue. For instance, here’s Play Store on my affected device (running Android 6.0.1):

Also, I seem to recall this only having started to affect Nextcloud quite recently, perhaps sometime in the past month or so.

Switching to dark mode is a workaround on my device at least (there the Android buttons are light-on-black). I can also confirm that the issue doesn’t affect my newer devices with newer Android.

I went back in time using F-droid’s dev archive, testing all the way to around when 3.9.2 was released (2019-12-07), and the issue persisted, so this is indeed some weird interaction with the latest server version(s) and particularly the conflicts detection thereof.

Version 20191206 (2019-12-07) exhibited the issue a bit differently, though probably just due to how handling of conflicts on the client end has changed between then and now: one file that did go through got renamed with ”(1)” added to it, even though there was no previously existing copy on the server. A previous attempt to upload the same file (using another client version) had failed, so that’s one possible explanation for why the server thought that a previous copy did exist.

Another file got seeminly stuck in the (client upload) queue, and watching the server log revealed that it was incrementing the added number continuously, always coming up with the same ”could not be located” exception from Sabre\DAV as above. It had run up to 80 when I cancelled the upload from the client, and would have perhaps run indefinitely if I didn’t.

{"reqId":"SmCGdnw4BzFQ5P25wMGV","level":0,"time":"2020-11-20T17:40:54+02:00","remoteAddr":"REDACTED","user":"testituutti","app":"webdav","method":"HEAD","url":"/varasto/remote.php/webdav/Testidataa/DSC_0003%20(75).JPG","message":{"Exception":"Sabre\\DAV\\Exception\\NotFound","Message":"File with name Testidataa/DSC_0003 (75).JPG could not be located","Code":0,"Trace":[{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":81,"function":"getNodeForPath","class":"OCA\\DAV\\Connector\\Sabre\\ObjectTree","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpGet","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":262,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpHead","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":251,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":319,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php","line":84,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/remote.php","line":167,"args":["REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php"],"function":"require_once"}],"File":"REDACTED/www/varasto/apps/dav/lib/Connector/Sabre/ObjectTree.php","Line":173,"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (Android) Nextcloud-android/20191207","version":"20.0.1.1"}
{"reqId":"M3RTK4KRuOH3N0xGrp2Q","level":0,"time":"2020-11-20T17:41:00+02:00","remoteAddr":"REDACTED","user":"testituutti","app":"webdav","method":"HEAD","url":"/varasto/remote.php/webdav/Testidataa/DSC_0003%20(76).JPG","message":{"Exception":"Sabre\\DAV\\Exception\\NotFound","Message":"File with name Testidataa/DSC_0003 (76).JPG could not be located","Code":0,"Trace":[{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":81,"function":"getNodeForPath","class":"OCA\\DAV\\Connector\\Sabre\\ObjectTree","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpGet","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":262,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpHead","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":251,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":319,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php","line":84,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/remote.php","line":167,"args":["REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php"],"function":"require_once"}],"File":"REDACTED/www/varasto/apps/dav/lib/Connector/Sabre/ObjectTree.php","Line":173,"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (Android) Nextcloud-android/20191207","version":"20.0.1.1"}

Previously reported in #4817.

@tobiasKaminsky Yup, tried it and the issue remains. Also found a device with 3.13.1, and it too is affected now, so this now seems more server-related, though it is weird that the desktop client hasn’t been affected at any point. I would have assumed both clients employ the same webdav commands (and thus fail or succeed just the same).

Syncing a folder in Android app’s ”all files” view also still works (i.e. downloading changes causes no issues).

I have another server instance on another host, and there uploading from Android still works. This (working) instance is unencrypted, while the non-working instance has server-side encryption enabled.

With more verbose logging server-side, there’s a ”Deprecated event type” followed by "Exception":"Sabre\\DAV\\Exception\\NotFound" for the file being uploaded. So it’s perhaps correctly reporting that the file (about to be uploaded) does not exist (yet), but for some reason the app receiving this message flips it around, thinking the file does exist, and thus reports a conflict.

Here’s a logcat snippet from another device. The result of ”Existence check” comes back as ”Name collision”, for any and all files.

This is still an issue, and always has been for Samsung devices with One UI’s scrolling screenshot feature.