I’ve got a PC running Opensuse Tumble weed that any version of the desktop client appimage does not retain login information after a reboot (or after a crash) and I’ve got another PC on the same operating system that works just fine. With that said, how do you COMPLETELY extract all data from an appimage? I’ve tried (as root) and somehow it is still remembering old account information. Finally frustrated! Where does this appimage store its data? PS - with or without KDEWallet enabled I still have the same issues. Since I use BitWarden I disabled KDEWallet.
Is there a specific reason why you are using the AppImage? I mean, since you’re using Tumbleweed, a rolling release distro, I’d assume the package from the Tumbleweed repos should be reasonably up to date at all times. I don’t use SUSE, but on both Fedora and Arch I use the distro packages and never had an issue where it doesn’t remember the credentials.
I’ve never used the AppImage myself, but in general, the client uses the QtKeychain API to store credentials. According to the README on their GitHub repo, it works as follows:
TL;DR: You should probably leave KWallet enabled. 
QtKeychain is a Qt API to store passwords and other secret data securely. How the data is stored depends on the platform:
- macOS: Passwords are stored in the macOS Keychain.
- Linux/Unix: If running, GNOME Keyring is used, otherwise QtKeychain tries to use KWallet (via D-Bus), if available. Libsecret (common API for desktop-specific solutions) is also supported.
- Windows: By default, the Windows Credential Store is used (requires Windows 7 or newer). Pass
-DUSE_CREDENTIAL_STORE=OFFto cmake to disable it. If disabled, QtKeychain uses the Windows API function CryptProtectData to encrypt the password with the user’s logon credentials. The encrypted data is then persisted via QSettings.- Android and iOS: Passwords are stored in the Android keystore system and iOS keychain, respectively.
1 Like
We discussed a very similar issue earlier this week in this thread:
2 laptops, 2 different desktop clients
My recommendation:
-
Just like @bb77 suggested, I recommend first checking what version is available in the Tumbleweed repos. Personally, I use CachyOS (also a rolling release based on Arch Linux), and the latest version of the Nextcloud client is always available very soon after it’s released – and it works reliably.
-
If the latest version isn’t available in the repositories, I prefer to use the Flatpak version instead. It’s more sandboxed, but it’s actively maintained, updated regularly, and behaves consistently across systems.
-
AppImage is my last resort, only if no other installation method works. I’ve had more issues with it compared to other distribution formats.
1 Like
Yep, and as far as I know, the AppImage also has the disadvantage of lacking overlay icons and not providing a context menu in the file manager.
Oh, and by the way, the package in the Tumbleweed repos is up to date: 
@bb77
Haha, you were faster than me – I was just about to check the Tumbleweed repo myself, but you beat me to it. 
Thanks for confirming that the official package is up to date!
Also, I have to say I really appreciate your knowledgeable and thorough responses.
Every time I come across one of your posts, I know it’s going to be well-explained and backed with real understanding of how things work under the hood.
It’s the kind of insight that adds real value to the forum. 
@JimmyTexas
Now that we know the Tumbleweed repository has the latest version of the Nextcloud client, I’d say forget about the AppImage altogether and just install it from the repos.
As @bb77 pointed out, AppImage lacks support for overlay icons and context menu integration in file managers – and yes, I know that pain very well myself. It’s one of the reasons I only consider AppImage as a last resort.
Use the repo version and you’ll likely get a much better and smoother experience overall.
But doesn’t the same apply to Flatpak? It’s unofficial too, so I’d probably consider it as a last resort. Either way, I suppose it would mostly come down to personal preference at that point.
Other than that, I fully agree. While storing credentials should work with the AppImage, it’s probably easier and more straightforward to just use the distro package, and it gets updated with your regular system updates, while the AppImage needs to be updated separately.
(Okay, the Flatpak, while updated separately as well, can be updated automatically, which might put it slightly ahead of the AppImage again. Tough choice, but luckily, it’s not one we really have to make on a rolling release distro. )
1 Like
In light of these options, how does one extract all data stored by the appimage before moving to the distro based package. I’ve also had the same issues on that PC running the FlatPak offering and those are pretty easy to extract data for as they all store under .var/app/ . Thank you.
It seems that factory repo is no longer available and the “install from opensuse” option is not an option in the “discover” application.
Unless you have terabytes of data on your Nextcloud that you need to re-sync, I wouldn’t recommend trying that. Just reconnect with the new client and let it re-sync the data.
Sorry, I don’t use openSUSE, so I’m not sure. But what happens if you try to install it via the command line, as described here: SDB:Nextcloud - openSUSE Wiki ?
zypper in nextcloud-desktop-dolphin nextcloud-client
I’ll report back on this if re-enabling KDEWallet doesn’t fix my issues. My Nextcloud instance has about 350gb on it, but until I replace the server with a NAS, it’s just an old PC with old mechanical drive in it. It’s on borrowed time I’m sure!
Just out of curiosity, I installed Tumbleweed in a VM and chose the KDE desktop option in the installer. And yeah, it’s definitely a bit weird how Discover behaves. It seems to prioritize Flatpaks, i.e. if a package is available as a Flatpak, it only finds that, and I couldn’t find any way to install the Nextcloud client from another repository through Discover.
However, running sudo zypper in nextcloud-desktop-dolphin nextcloud-client via Konsole worked just fine, and the package then also appears as installed in YaST. So if you prefer using a GUI to install packages, you can likely find and install it from there as well.
I’ll likely do that command line install. I do like FlatPaks, but not for everything.
1 Like
This topic was automatically closed after 90 days. New replies are no longer allowed.