[Bug]: Nextcloud Client 3.14.0 Crashes with Virtual File support / vfs enabled

[mattie-cmsp]

⚠️ 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

After updating to Nextcloud client 3.14.0, the client crashes either when enabling Virtual Files support, or if an existing configuration contains already enabled virtual file folders(will crash on startup).

Shortly before the crash, I found this in the logs:
2024-09-23 17:01:41:058 [ warning qt.core.qobject.connect unknown:0 ]: QObject::connect(QDialog, OCC::AccountSettings): invalid nullptr parameter

nextcloud-debug.zip

Steps to reproduce

1. Click the ... in settings next to a sync folder
2. Click to Enable Virtual Files support
   Client will crash after this.

If an already existing Virtual Files folder is in the configuration, simply start the client, it will crash on start.

Expected behavior

When clicking Enable Virtual Files support, Virtual File mode should be enabled for the folder.

If an already existing virtual files folder existing in the configuration, Nextcloud client should start and sync as normal.

Which files are affected by this bug

Nextcloud Client

Operating system

Linux

Which version of the operating system you are running.

Garuda Linux 6.10.5 Kernel, KDE Plasma 6.1.5, Wayland

Package

Official Linux AppImage

Nextcloud Server version

29.0.7

Nextcloud Desktop Client version

3.14.0

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

No response

Additional info

This might be the cause of other crash on start bugs

[t3nk3y]

I'm the OP, posted to the wrong account initially.

This issue doesn't occur on NC 3.13.4
For anyone in a critical state and willing to use the AppImage, here is the previous release URL:
https://github.com/nextcloud-releases/desktop/releases/download/v3.13.4/Nextcloud-3.13.4-x86_64.AppImage

I believe PR# 6803 may have introduced the faulting code. The AppImage attached to that PR crashes with the following error:
2024-09-23 17:45:51:018 [ critical plugins /drone/src/src/common/vfs.cpp:241 ]: Could not load plugin: not existent or bad metadata "nextcloudsync_vfs_suffix" 2024-09-23 17:45:51:018 [ fatal default /drone/src/src/gui/folderman.cpp:317 ]: Could not load plugin
#6803

[boray-tw]

I encountered the same problem after upgrading the desktop client to 3.14.0 in Arch Linux.

Solution

Following the clue of this commit of the package nextcloud-client in Arch Linux, I fixed the problem by moving the library nextcloudsync_vfs_suffix.so from /usr/lib/ to the plugin directory of Qt6, similar to what FlexW did in #3781 and what palto42 did in #3668.

sudo mv -i /usr/lib/nextcloudsync_vfs_suffix.so /usr/lib/qt6/plugins/

My Environment

• OS: ArcoLinux, Linux kernel 6.10.10-arch1-1 x86_64
• Nextcloud server version: 28.0.9
• Nextcloud desktop client version: 3.14.0 (2:3.14.0-5 in Arch Linux)
• Qt version: 6.7.2

Nextcloud Desktop Logs

I quoted only relevant information from the last log in ~/.config/Nextcloud/logs.

2024-09-24 11:34:25:529 [ info nextcloud.gui.folder.manager /usr/src/debug/nextcloud-client/nextcloud-client/src/gui/folderman.cpp:186 ]:	Setup folders from settings file
2024-09-24 11:34:25:529 [ critical plugins /usr/src/debug/nextcloud-client/nextcloud-client/src/common/vfs.cpp:241 ]:	Could not load plugin: not existent or bad metadata "nextcloudsync_vfs_suffix"
2024-09-24 11:34:25:529 [ fatal default /usr/src/debug/nextcloud-client/nextcloud-client/src/gui/folderman.cpp:317 ]:	Could not load plugin

Under the [General] section in ~/.config/Nextcloud/nextcloud.cfg, I set isVfsEnabled=false, but I set showExperimentalOptions=true and enabled virtual file support for my account before upgrading the client to 3.14.0. As a result, the client tries to loads the VFS plugin from Qt.

My Traceback

1. In src/common/vfs.cpp, we reach line 241 because the condition in line 240.
2. Line 240 calls isVfsPluginAvailable with VFS mode suffix.
3. In line 163 QPluginLoader tries to load the library nextcloudsync_vfs_suffix from the Qt plugin directory. Since Nextcloud desktop client 3.14.0 uses Qt6, the default plugin directory is /usr/lib/qt6/plugins/.
4. There is no nextcloudsync_vfs_suffix.so under /usr/lib/qt6/plugins/. The same library is under /usr/lib/ instead.

[t3nk3y]

I can confirm, this workaround does the trick. So it sounds like a packaging issue, then? Trying to figure out if this is downstream. The appimage also has the problem, and contains it's own FS, so I'd assume this needs to be handled in the NC packaging process.

[thibaultmol]

Interesting, for what it's worth I actually installed 3.14.0 (I installed nextcloud client for the first time on this machine, wonder if this has something to do with it).
But I'm not having this problem.

Nextcloud server is 29.0.6

Operating System: NixOS 24.11
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.2
Kernel Version: 6.6.51 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics
Memory: 60.6 GiB of RAM
Graphics Processor: AMD Radeon 780M
Manufacturer: Framework
Product Name: Laptop 13 (AMD Ryzen 7040Series)
System Version: A7

[t3nk3y]

Interesting, for what it's worth I actually installed 3.14.0 (I installed nextcloud client for the first time on this machine, wonder if this has something to do with it). But I'm not having this problem.

Nextcloud server is 29.0.6

Operating System: NixOS 24.11

Since you are on NixOS and we are on Arch, that could explain the difference. NixOS seems to have a fairly unique packaging system.

[bigretromike]

For now I can confirm there is no issue on Win11 64bit

[boray-tw]

Sorry. The solution I mentioned above may also break the Nextcloud client when a new client version rolls in. The plugin is better be a symbolic link as a workaround. A symlink also prevents pacman warning of an absent file (moved library in /usr/lib).

sudo ln -s /usr/lib/nextcloudsync_vfs_suffix.so /usr/lib/qt6/plugins/nextcloudsync_vfs_suffix.so

[t3nk3y]

While we have a good workaround here, I just want to be sure that once someone gets around to triaging this, they know this workaround can guide them to a proper solution, but isn't an actual solution.

Users should def not be needing to manually create symlinks after installation for the program to work.

[aleixq]

As this may be an archlinux packaging issue, there's an issue in https://gitlab.archlinux.org/archlinux/packaging/packages/nextcloud-client/-/issues/8

[t3nk3y]

As this may be an archlinux packaging issue, there's an issue in https://gitlab.archlinux.org/archlinux/packaging/packages/nextcloud-client/-/issues/8

If this also happens with the Appimage, should something be opened elsewhere for the Appimage package?

[Ador-able]

I encountered the same problem on the window
I tried to fix the crash issue with the version I am using, but it failed
#7258 (comment)

2024-10-10 16:15:29:721 [ warning qt.core.qobject.connect unknown:0 ]: QObject::connect(QNetworkInformation, OCC::Application): invalid nullptr parameter
2024-10-10 16:15:29:721 [ warning nextcloud.sync.configfile C:\Users\User\AppData\Local\Temp\windows-26298\client-building\desktop\src\libsync\configfile.cpp:718 ]: Enforcing default update channel "stable"
2024-10-10 16:15:29:721 [ warning nextcloud.sync.configfile C:\Users\User\AppData\Local\Temp\windows-26298\client-building\desktop\src\libsync\configfile.cpp:728 ]: Config file has a valid update channel: "stable"
2024-10-10 16:15:30:099 [ warning qt.qml.context unknown:0 ]: qrc:/qml/src/gui/tray/MainWindow.qml:313:29 Parameter "index" is not declared. Injection of parameters into signal handlers is deprecated. Use JavaScript functions with formal parameters instead.
2024-10-10 16:15:30:103 [ warning qt.qml.context unknown:0 ]: qrc:/qml/src/gui/tray/MainWindow.qml:314:29 Parameter "object" is not declared. Injection of parameters into signal handlers is deprecated. Use JavaScript functions with formal parameters instead.
2024-10-10 16:15:30:367 [ warning nextcloud.gui.account.manager C:\Users\User\AppData\Local\Temp\windows-26298\client-building\desktop\src\gui\accountmanager.cpp:536 ]: Failed to read proxy password to keychain "Password entry not found"

[joshrandall8478]

Having this issue as well

[boray-tw]

The issue has been "partially" (?) resolved on Arch Linux based distributions since 3.14.2-2 because of this commit in nextcloud-client (Arch Linux package). Thanks @aleixq for pointing out issue 8 of nextcloud-client. And thanks @thibaultmol for the clue of packaging problem in Arch Linux.

If you adapted the symlink workaround above, please unlink or remove the symlink before updating the nextcloud-client package.

sudo unlink /usr/lib/qt6/plugins/nextcloudsync_vfs_suffix.so

@t3nk3y, does the daily AppImage version work on your machine now? I think the build-appimage.sh script already fixed the plugin directory issue with commit a5cb5d6 (lines 60-61) in 2022. And the update in nextcloud-client might not help you.

As for #7258, it is not yet resolved in v3.14.2. Sorry @Ador-able.

[t3nk3y]

Can confirm the arch update fixed the repository version. And the AppImage is working now as well. Though, I didn't try uninstalling the arch repository version to see if AppImage still works without the so's that the repository version had there.

But I think the AppImage should be looking at it's own filesystem anyway?

[maboxx]

Hello everyone,
I also had big problems when updating from 3.13.3 to 3.14.3.
In the end I didn't have a crash anymore but the data was downloaded even though I had activated virtual files.
I have now uninstalled nextcloud-client and deleted the .config/Nextcloud folder in Linux.
After reinstalling 3.14.3 everything seems to work. However, I have not yet been able to reboot......
I have activated the Eperimental Option in nextcloud.cfg and then activated the virtual files in the GUI.
What exactly does this option "isVfsEnable=false" do in the config if I set it to true?
`
clientVersion=3.14.3daily
desktopEnterpriseChannel=daily
isVfsEnabled=false
showExperimentalOptions=true

`

Greetings
maboxx

[maboxx]

Too bad :-( The version 3.14.3 has worked 2-3 reboots. At some point it starts to download the files instead of handling them “virtually”. The result was the storage on my notebook was full.
I have had this behavior twice now.
I have now deleted the version and all files locally and reinstalled version 3.13.3.
Before I logged in, I activated this functions in nextcloud.cfg.
"isVfsEnabled=true"
"showExperimentalOptions=true"

Then I logged in and configured my synchronization with virtual data. I hope this procedure is the right one.

I hope that version 3.13.3 will now work reliably again and that a newer version will be tested again at some point. I hope the problems are fixed in a future version.

EDIT: Update now to 3.13.4 and also everything is good. Seems I have trouble when I update to 3.14.x. So I think I'll stay on 3.13.4 for a few more versions and test it again sometime, hopefully with more luck.

[MagicDM]

I've also been experiencing instant crashing (upon attempted launch) with virtual files enabled (on all of the 3.14.* and now the most recent 3.15.0 versions of the desktop client appimage).

Most recent version tried:
Nextcloud-3.15.0-x86_64.AppImage

OS Fedora Linux 38

clientVersion=3.15.03.15 (build 27020)
isVfsEnabled=false
showExperimentalOptions=true

I'm still running Nextcloud-3.12.2-x86_64.AppImage and, sadly, cannot upgrade until this issue is resolved.

Thank you in advance to the team for all of their work and help.

[maboxx]

I have now updated the client to 3.15.0 on my test machine with archlinux..... so far it looks good, no crashes and it seems that the “virtual” files work.... can anyone else confirm this?

clientVersion=3.15.0daily
isVfsEnabled=false
showExperimentalOptions=true

I'll keep watching.

[maboxx]

It's such a bummer. Constantly “Nextcloud desktop client not responding”, so hangs up. So I'm sticking with 3.13.4 :-(
Is 3.15.0 working for anyone now?