nextcloud / desktop

💻 Desktop sync client for Nextcloud
https://nextcloud.com/install/#install-clients
GNU General Public License v2.0
2.97k stars 781 forks source link

client causing keyring file to be rewritted every few seconds #1592

Closed madpilot78 closed 4 years ago

madpilot78 commented 4 years ago

Expected behaviour

I expect the client to save the credentials when they are actually created or changed and then leave the information as is

Actual behaviour

I have noticed the keyring file is continuously updated, every few seconds. I noticed this because I keep my home directory in sync using unison, here is an excerpt from the log:

UNISON 2.51.2 (OCAML 4.05.0) started propagating changes at 11:59:16.47 on 08 Nov 2019
[BGN] Updating file .local/share/keyrings/Default_keyring.keyring from /usr/home/mad to //micro.madpilot.net//home/mad
[END] Updating file .local/share/keyrings/Default_keyring.keyring
UNISON 2.51.2 (OCAML 4.05.0) finished propagating changes at 11:59:16.48 on 08 Nov 2019
Synchronization complete at 11:59:16  (1 item transferred, 0 skipped, 0 failed)
UNISON 2.51.2 (OCAML 4.05.0) started propagating changes at 11:59:19.37 on 08 Nov 2019
[BGN] Updating file .local/share/keyrings/Default_keyring.keyring from /usr/home/mad to //micro.madpilot.net//home/mad
[END] Updating file .local/share/keyrings/Default_keyring.keyring
UNISON 2.51.2 (OCAML 4.05.0) finished propagating changes at 11:59:19.38 on 08 Nov 2019
Synchronization complete at 11:59:19  (1 item transferred, 0 skipped, 0 failed)
UNISON 2.51.2 (OCAML 4.05.0) started propagating changes at 11:59:24.39 on 08 Nov 2019
[BGN] Updating file .local/share/keyrings/Default_keyring.keyring from /usr/home/mad to //micro.madpilot.net//home/mad
[END] Updating file .local/share/keyrings/Default_keyring.keyring
UNISON 2.51.2 (OCAML 4.05.0) finished propagating changes at 11:59:24.40 on 08 Nov 2019
Synchronization complete at 11:59:24  (1 item transferred, 0 skipped, 0 failed)

From the nextcloud client I found this repeatedly:

[unknown    static bool LibSecretKeyring::writePassword(const QString &, const QString &, const QString &, const QKeychain::JobPrivate::Mode, const QByteArray &, QKeychain::JobPrivate *)
[OCC::Account::setAppPassword(QString)::(anonymous class)::operator()   appPassword stored in keychain

This looks like a default behaviour caused by https://github.com/nextcloud/desktop/blob/5775ec1ff1f3c65810d9c8ebd1f75b5280a0583d/src/gui/creds/webflowcredentials.cpp#L423

I'm going to test compiling the client with that line commented out. I understand it's not a permanent fix, but will at least indicate if that line is actually the cause.

Steps to reproduce

1.install 2.connect a nexcloud account

Client configuration

Client version: 2.6.1

Operating system: FreeBSD

OS language: Default (C - english)

Qt version used by client package (Linux only, see also Settings dialog):Qt 5.13.0

Client package (From Nextcloud or distro) (Linux only):FreeBSD nextcloud port updated to latest version

Installation path of client: default, /usr/local/

Server configuration

Nextcloud version:

Storage backend (external storage):

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer logs.

  1. Client logfile: Output of nextcloud --logwindow or nextcloud --logfile log.txt (On Windows using cmd.exe, you might need to first cd into the Nextcloud directory) (See also https://docs.nextcloud.com/desktop/2.3/troubleshooting.html#log-files)

  2. Web server error log:

  3. Server logfile: nextcloud log (data/nextcloud.log):

brrrrrrrt commented 4 years ago

using nextcloud-client-2.6.1-2-x86_64 from arch community repo

not sure if this is related, but i experience gnome-keyring-daemon "running amok" with latest version, it consumes lots of cpu, conky reports constantly 20-30M IO write (!!).

i have ~10 Folders "in sync" on 3 different Servers, strange behaviour stops as soon i "stop all synchronizations" and continues if i start it again.

downgrading to V2.6.0 fixes the problem

madpilot78 commented 4 years ago

downgrading to V2.6.0 fixes the problem

The line I pointed out comes from this commit: 19491ff85f3cd02952478d2ee1fb42caf252e9dd

It is four months old, so it was included in 2.6.0 too. But I don't know if this is interacting with something else.

pwfrank commented 4 years ago

It is four months old, so it was included in 2.6.0 too. But I don't know if this is interacting with something else.

As far as I can tell, https://github.com/nextcloud/desktop/commit/19491ff85f3cd02952478d2ee1fb42caf252e9dd was only merged ~3 weeks ago ( #1504 ) and was only just included in the 2.6.1 release https://github.com/nextcloud/desktop/releases/tag/v2.6.1

I'm seeing what seems to be a related issue in which Nextcloud is continually trying to register the Default Keyring in gnome-keyring-daemon. (Arch Linux, nextcloud-client 2.6.1-2 x86_64). Downgrading to 2.6.0 solved the issue for me as well

madpilot78 commented 4 years ago

This looks like a default behaviour caused by

https://github.com/nextcloud/desktop/blob/5775ec1ff1f3c65810d9c8ebd1f75b5280a0583d/src/gui/creds/webflowcredentials.cpp#L423

I'm going to test compiling the client with that line commented out. I understand it's not a permanent fix, but will at least indicate if that line is actually the cause.

I can now confirm that commenting out the above line in the source code makes tha unwanted behaviour disappear.

I understand this is no fox. It looks like this was added to properly implement the "remote wipe" functionality, and I don't know the details of how that works.

Someone who knows that code should take a better look here.

dkaparis commented 4 years ago

using nextcloud-client-2.6.1-2-x86_64 from arch community repo

not sure if this is related, but i experience gnome-keyring-daemon "running amok" with latest version, it consumes lots of cpu, conky reports constantly 20-30M IO write (!!).

i have ~10 Folders "in sync" on 3 different Servers, strange behaviour stops as soon i "stop all synchronizations" and continues if i start it again.

downgrading to V2.6.0 fixes the problem

To add to this, when running nextcloud-client-2.6.1-2-x86_64 on my system, gnome-keyring-daemon entries are continuously spammed in my system log:

gnome-keyring-daemon[774]: asked to register item /org/freedesktop/secrets/collection/login/179, but it's already registered
gnome-keyring-daemon[774]: asked to register item /org/freedesktop/secrets/collection/login/178, but it's already registered
...

Again, V2.6.0 does not exhibit this.

archont00 commented 4 years ago

I tried to delete all items in seahorse and re-register nexctloud client again, however, the spamming our system log continued. Downgrading. (Arch Linux).

ldesgrange commented 4 years ago

I have a similar issue on macOS (10.13.6) and Nextcloud client 2.6.1. Lots of logs about nextcloud, securityd and Keychain:

Subsystem: com.apple.securityd Category: security_exception 23:26:52.738269 +0100   nextcloud   UNIX error exception: 17
Subsystem: com.apple.securityd Category: policy         23:26:53.328110 +0100   trustd      cert[0]: TemporalValidity =(path)[]> 0
Subsystem: com.apple.securityd Category: SecError       23:26:53.328731 +0100   nextcloud   Trust evaluate failure: [leaf TemporalValidity]
Subsystem: com.apple.securityd Category: security_exception 23:26:55.856622 +0100   securityd   MacOS error: -67050
Subsystem: com.apple.securityd Category: clientid       23:26:55.858304 +0100   securityd   code requirement check failed (-67050), client is not Apple-signed
Subsystem: com.apple.securityd Category: security_exception 23:26:55.862179 +0100   nextcloud   CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
Subsystem: com.apple.securityd Category: integrity      23:26:55.883141 +0100   nextcloud   possible duplicate, trying to delete invalid items
Subsystem: com.apple.securityd Category: integrity      23:26:55.883795 +0100   nextcloud   no unique id, using 6 attributes from mDbAttributes
Subsystem: com.apple.securityd Category: integrity      23:26:55.889692 +0100   nextcloud   duplicate item exception is real; throwing it on
Subsystem: com.apple.securityd Category: security_exception 23:26:55.905105 +0100   securityd   MacOS error: -67050
Subsystem: com.apple.securityd Category: clientid       23:26:55.906420 +0100   securityd   code requirement check failed (-67050), client is not Apple-signed
Subsystem: com.apple.securityd Category: atomicfile     23:26:55.918648 +0100   nextcloud   0x6040010e2700 commited /Users/me/Library/Keychains/login.keychain-db.sb-… to /Users/me/Library/Keychains/login.keychain-db
Subsystem: com.apple.securityd Category: servermode     23:26:55.919807 +0100   securityd   keychain reference in server mode

After a few hours, macOS tells me that Nextcloud clients has written 200GB (!) of data on the hard drive (while only a couple of small text files have been modified).

misch7 commented 4 years ago

For Linux:

Did you try the AppImage? Does the error still occur there too? https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.6.1-x86_64.AppImage

For macOS:

@ldesgrange Which build of 2.6.1 did you install?

New release build for macOS 10.12+, notarized by Apple at 2019-11-16: https://download.nextcloud.com/desktop/releases/Mac/Installer/Nextcloud-2.6.1.20191105.pkg

Legacy build for macOS 10.10 - 10.11 with older Qt and OpenSSL, not notarized (previously used build chain): https://download.nextcloud.com/desktop/releases/Mac/Installer/Nextcloud-2.6.1.20191104-legacy.pkg

madpilot78 commented 4 years ago

For Linux:

Did you try the AppImage? Does the error still occur there too? https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.6.1-x86_64.AppImage

As I stated I'm using FreeBSD and compiling the FreeBSD port. The appimage is not an option for me.

Anyway I did identify the line of code causing this behaviour. I am unable to propose a full patch because I don't know how the remote wipe works. But it definitely needs some change to the line I reference in my first message.

brrrrrrrt commented 4 years ago

Did you try the AppImage? Does the error still occur there too? https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.6.1-x86_64.AppImage

yes, just tried and i can confirm, this version shows the exact same behaviour.

pwfrank commented 4 years ago

Did you try the AppImage? Does the error still occur there too?

@misch7 I can confirm this issue occurs on the AppImage as well. Both @madpilot78's workaround in https://github.com/nextcloud/desktop/issues/1592#issuecomment-552102211 and downgrading to 2.6.0 resolve the issue for me

misch7 commented 4 years ago

Thanks @brrrrrrrt and @pwfrank ! It's helpful to know, that the issue occurs on the AppImage as well.

And thanks @madpilot78, we'll look into that.

ldesgrange commented 4 years ago

@ldesgrange Which build of 2.6.1 did you install?

New release build for macOS 10.12+, notarized by Apple at 2019-11-16: https://download.nextcloud.com/desktop/releases/Mac/Installer/Nextcloud-2.6.1.20191105.pkg

Yes, I'm using that version: Version 2.6.1stable (build 20191105).

localguru commented 4 years ago

Same on Xubuntu 19.10

ii  libnextcloudsync0                     2.6.1-20191017.124538~eoan1          amd64        Nextcloud sync library
ii  nextcloud-client                      2.6.1-20191017.124538~eoan1          amd64        Nextcloud desktop sync client
ii  nextcloud-client-l10n                 2.6.1-20191017.124538~eoan1          all          Nextcloud client internatialization files
localguru commented 4 years ago

/etc/rsyslog.d/10-nextcloud_client.conf:

:msg,contains,"asked to register item /org/freedesktop/secrets/collection/login/" ~
JPKCom commented 4 years ago

I have the same behavior with version 2.6.1(stable) for macOS. My macOS version is: 10.14.6 (18G1012) The client writes approx. 100 GB to the hard disk within approx. 8 hours. The following messages appear in the log of macOS every 2.5 seconds:

standard    16:04:24.664872 +0100    trustd    asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (nextcloud[420]/0#-1 LF=0)
standard    16:04:24.707079 +0100    nextcloud    CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard    16:04:24.708908 +0100    nextcloud    CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard    16:04:24.710825 +0100    nextcloud    CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard    16:04:24.712520 +0100    nextcloud    possible duplicate, trying to delete invalid items
standard    16:04:24.712882 +0100    nextcloud    no unique id, using 6 attributes from mDbAttributes
standard    16:04:24.717640 +0100    nextcloud    duplicate item exception is real; throwing it on
standard    16:04:24.717718 +0100    nextcloud    caught CssmError during add: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard    16:04:24.757442 +0100    nextcloud    0x6000035d1880 commited /Users/USER/Library/Keychains/login.keychain-db.sb-ea826489-sQ1OrK to /Users/USER/Library/Keychains/login.keychain-db
standard    16:04:24.779662 +0100    nextcloud    0x6000035d1800 commited /Users/USER/Library/Keychains/login.keychain-db.sb-ea826489-2ZmJPj to /Users/USER/Library/Keychains/login.keychain-db
standard    16:04:24.792280 +0100    trustd    asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (nextcloud[420]/0#-1 LF=0)
standard    16:04:24.819734 +0100    nextcloud    no previous integrity acl exists; making a new one
standard    16:04:24.844267 +0100    nextcloud    0x600003628200 commited /Users/USER/Library/Keychains/login.keychain-db.sb-ea826489-KYw1tL to /Users/USER/Library/Keychains/login.keychain-db

An attempt was made to reinstall the client (2.6.1) over the existing version as well as to completely delete and then reinstall the client (2.6.1). I also logged the client off and logged it back on to the server. This didn't bring any success. Additionally I closed the client, removed all entries from it in the macOS keychain by hand and registered it again on the server. This didn't bring any success either.

The only current solution was a downgrade to client version 2.5.3.

n1ete commented 4 years ago

Just want to confirm the same logspam error on an fresh installed & updated Arch Linux. I didnt investigate it for now but can provide logs if needed.

lkrms commented 4 years ago

While waiting for this to be fixed and released, can I ask where others are getting 2.6.0 debs from? (assuming you're using deb packages)

I'd prefer not to start using AppImages just for this :thinking:

Previous versions (but not 2.6.0) appear here: http://ppa.launchpad.net/nextcloud-devs/client/ubuntu/pool/main/n/nextcloud-client/

So far it looks like I'll need to build it myself or use Debian's repos.

mnlipp commented 4 years ago

As the cause has already been analyzed, this is OS independent. Nevertheless, confirmed for nextcloud-client-2.6.1-1.fc30.x86_64 (and I had been so happy that the new version finally appeared in the repos and the annoying update message subsided).

rdica commented 4 years ago

Problem confirmed with nextcloud-client-2.6.1-1.fc29.x86_64 as well.

misch7 commented 4 years ago

This has been fixed by #1646.

Linux: Please use this AppImage build to test it: https://github.com/nextcloud/desktop/issues/1292#issuecomment-560008811

The fix will get into the 2.6.2 release.

madpilot78 commented 4 years ago

@misch7 Thanks a lot for the fix!

After a quick test I can confirm it works fine on FreeBSD.