[Bug]: starting a second client marks all folders in Nextcloud root for syncing
- Dominant language
- C++
- Stars
- 3.9k
- Forks
- 1k
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 123
Description
### ⚠️ Before submitting, please verify the following: ⚠️
- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github (I've searched it).
- [x] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)
### Bug description
**Issue:** If I run the Desktop Client from my Window Manager (WM), and then run it again as an XDG Autostart via Desktop Environment (DE), all the folders in my Nextcloud root become marked for syncing.
**Backstory:** I was playing around with AwesomeWM as my Window Manager and XFCE4 Desktop Environment in the background to run some helpful stuff like power manager. My AwesomeWM is configured to run the Client on WM start (`nextcloud --background`) as well as start XFCE tools. The Client also has an autostart file, so when AwesomeWM restarts, it runs the Client, and then XFCE starts a *second* Client via autostart.
When the second Client opens, all the folders in my Nextcloud root are marked for syncing. Usually, I only sync a couple, so this "second Client" seems to have caused all the folders to be marked for syncing.
If I run a second Client manually from Bash (`nextcloud --background`), the folders do *not* become marked for syncing.
Errors produced by this manually run Client and which appear in the Systemd Journal when running the Client with autostart:
```
Failed to initialize instances shared memory: "QSharedMemory::handle: doesn't exist"
QGuiApplication::setDesktopFileName: the specified desktop file name ends with .desktop. For compatibility reasons, the .desktop suffix will be removed. Please specify a desktop file name without .desktop suffix
nextcloud.gui.application: Migrating old config from "/home/lh/.local/share/Nextcloud" to "/home/lh/.config/Nextcloud"
nextcloud.gui.application: Failed to move the old config directory to its new location ( "/home/lh/.local/share/Nextcloud" to "/home/lh/.config/Nextcloud" )
nextcloud.gui.application: Will move the individual files QList("nextcloud-sync_sync.log")
nextcloud.gui.application: Fallback move of "nextcloud-sync_sync.log" also failed
```
(For reference, my sync folder is named `nextcloud-sync`).
I'd imagine that, by default, only one instance of the Client should be allowed to run?
I'm marking `/home/lh/.local/share/Nextcloud` as an affected file because these errors appear in the journal, and maybe are a symptom of the bug?
### Steps to reproduce
1. Run Client with "autorun" shell script from AwesomeWM:
```bash
autorun() {
if ! pgrep -f "$1"; then
$@ &
fi
}
autorun 'nextcloud --background'
```
2. Also run Client from XDG autostart file on WM start.
3. Second Client opens in systray and all folders marked for syncing.
### Expected behavior
Second Client should not mark all folders for syncing.
### Which files are affected by this bug
/home/lh/.local/share/Nextcloud/
### Operating system
Linux
### Which version of the operating system you are running.
Arch
### Package
Distro package manager
### Nextcloud Server version
25.0.13
### Nextcloud Desktop Client version
3.15.0daily
### Is this bug present after an update or on a fresh install?
Fresh desktop client install
### Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
### Are you using an external user-backend?
- [ ] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
### Nextcloud Server logs
```shell
```
### Additional info
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.