Just made a new install with 13.1p2 and quarterly packages, same thing, "Host not found" after successfully syncing around 35 out of 80GB.

As before, going from "No Proxy" to "Use system proxy" makes the sync restart but then dies again.

I, too, am experiencing this KDE Plasma on 13.2 fresh install. It’s in a VM. Will try on bare metal as I get time.

Well, happy to hear I am not alone.
Something is clearly wrong with Qtnetwork-> nextcloudclient but beats me what.

Only thing I discovered is that it works better if started from a terminal window than from a menu.

It would be great to have advise on how to drill down to the real problem...

I've cloned and built the latest from https://github.com/nextcloud/desktop (which built quite cleanly, I may add!)

Once I ran it from the build directory I'm getting the same errors. My uneducated guess would seem that the error would either lie in abstractnetworkjob or the interface between abstractnetworkjob and the OS resolver. I do find it strange that the call has a URL, but the abstractnetworkjob debug line has an empty url.

Man I wish I had more experience with QT to track this down.

Also for "giggles" I added my nextcloud server to /etc/hosts and got the same error, so it's not an external dns resolver issue

Good news / Bad News on my tests.

I installed it on real hardware, and I'm not getting the error (same OS version, same basic install). In my experience so far it's *got* to be a VMWare/OpenVM Network Driver issue. I have heck with Desktop integration in a VM box anyways.

I was mistaken. It took *much* longer to get to the error, but it, indeed, gave the same "hostname not found" error as we've been experiencing.

Comment 8 Graham Perrin 2023-08-20 22:48:04 UTC

(In reply to peo from comment #0)

> … the "Host not found" error is not confined to FreeBSD …

Your next step might be an upstream bug report – if there's not one already, and if you can provide steps to reproduce. 

<https://github.com/nextcloud/desktop/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+host+not+found>

I have had the problem now for years through several FreeBSd and port versions, no change.
Since I now reverted to starting the client in a terminal, a simple Ctrl+C/Arrow+Up/Enter a couple of times a day fixes it, 
Unfortunately at the moment I do not have the time to pursue the issue.
Thanks,
Per

Great news. 3.9.3 in ports (updated on Aug 26th?) seems to have fixed the problem. 10gb transferred so far with no failure notices.

Thank you, madpilot!

(In reply to peo from comment #3)

I have the same problem since over a year with GhostBSD.

(In reply to Jeffrey Gordon from comment #10)

I still have this issue with version 3.9.3.  :-(

Only with FreeBSD (GhostBSD). 

Windows, Linux and Mac clients have no issue (Same network, same nc server).

(In reply to Manfred Usselmann from comment #12)

Btw. syncing with nextcloudcmd works without issues. At least if you do it for the top level folders one by one.

E.g. 

nextcloudcmd -u (user) -p (password) --path /(Folder1)/ (local/path/)(Folder1)/ https://(nc_server).(tld)
nextcloudcmd -u (user) -p (password) --path /(Folder2)/ (local/path/)(Folder2)/ https://(nc_server).(tld)

To me this shows that there is no real network problem but something is wrong with the combination of the nextcloud client, qt5 and FreeBSD.

Again I was mistaken. It takes too long for this error to raise its ugly head sometimes. 

I've created an Issue at Nextcloud's Desktop Client github.

https://github.com/nextcloud/desktop/issues/6024

The same problem persists in 14.0-BETA2

I repeat my previous comment that if you do not include nectcloudclient with X startup, just start from a shell, it will stay up longer, not forever, but longer.

A mysterious one this is. We really need someone with Qt knowledge to sort this.

Ep, kinda double posting from upstream issue in case it is actionable on this side:

Checking v3.10.0 release notes, I see https://github.com/nextcloud/desktop/pull/5036/files which could happen to address these issues or, at least from the looks of the code: help with the debugging because it has more detailed error logging.

I sadly lack the time now to check this hypothesis (building QT takes ages), is there a chance we could update the port on the tree so it eventually gets built?

I'm getting the same problem with compiled from the latest github source still

-----------------------------------------------------------

jeff@freebsd140 ~/Downloads/desktop/build/bin (master) $ ./nextcloud --version
QML debugging is enabled. Only use this in a safe environment.
nextcloud.gui.application: Migrating old config from "/home/jeff/.local/share/Nextcloud" to "/home/jeff/.config/Nextcloud"
nextcloud.gui.application: Failed to move the old config directory to its new location ( "/home/jeff/.local/share/Nextcloud" to "/home/jeff/.config/Nextcloud" )
nextcloud.gui.application: Will move the individual files ("Nextcloud_sync.log")
nextcloud.gui.application: Fallback move of  "Nextcloud_sync.log" also failed
Nextcloud version 3.10.50git
Git revision 29e8c8918100f0c071aac25e4fdf4facaa3c4c10
Using Qt 5.15.8, built against Qt 5.15.8
Using Qt platform plugin 'xcb'
Using 'OpenSSL 3.0.10 1 Aug 2023'
Running on FreeBSD 14.0-BETA2, x86_64
jeff@freebsd140 ~/Downloads/desktop/build/bin (master) $

Continuing on my observatsions as I test, I've noticed that some remote folders work just fine and some just fail with Host Not Found. Most of these errors stem from a long URL path such as deep into a .git repository folder.

I wonder if it could be a variable CONST size issue in the QT abstractnetworkjob or other library which is cutting the variable off.

Thoughts? I'm mirroring this brainstorm at 
https://github.com/nextcloud/desktop/issues/6024

Here's my latest addition to this mystery.

fstatat(AT_FDCWD,"/etc/ssl/certs//8d33f237.0",0x2b4ce807cfa0,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/lib/ssl/certs//8d33f237.0",0x2b4ce807cfa0,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/share/ssl//8d33f237.0",0x2b4ce807cfa0,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/local/ssl//8d33f237.0",0x2b4ce807cfa0,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/var/ssl/certs//8d33f237.0",0x2b4ce807cfa0,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/local/ssl/certs//8d33f237.0",0x2b4ce807cfa0,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/etc/openssl/certs//8d33f237.0",0x2b4ce807cfa0,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/opt/openssl/certs//8d33f237.0",0x2b4ce807cfa0,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/etc/ssl//8d33f237.0",0x2b4ce807cfa0,0x0) ERR#2 'No such file or directory'

Which cert is 0x2b4ce807cfa0 that apparently not found?

What we need here is that somebody with the right knowledge steps in and provide what debuging info is needed to be able to sort this years long problem. Where is this precious person? With Nextcloud Gmbh?

Comment 22 Philip Jocks 2025-10-01 10:48:31 UTC

running nextcloud 3.17.2 from the command line returns this error:

/usr/local/share/libdrm/amdgpu.ids: Too many open files

Anyone else seeing this?

(In reply to Philip Jocks from comment #22)

No, never seen this, are on 3.17.1.

Do you have an extraordinary number of files stored? Our count is 2177358 today.

Per

Comment 24 Philip Jocks 2026-01-11 12:58:48 UTC

is this still an issue for anyone? Seems like it went away, at least, I haven't seen it in a while. On 4.0.3 now

FWIW: I kept seeing it until not long ago, but after debugging the situation a lot, I figured that NC had written some bogus configuration to the keyring.

In the end what I did was manually deleting everything related to NC in the keyring file (~/.local/share/keyrings/....keyring), and manually add one by one the NC accounts again to the nextcloud installation.

After that the issue went away.


I'd think some version of NC had a bug that hit some people for some time, but was perpetuated in the config, we can probably close this safely and hopefully this explanation helps someone that still has it to go back to a reasonably stable state.

Still happens here, are on 4.0.3

Have you tried fixing the configuration the way I described?

No, did not try yet.
The passwords in my case are in 
.local/share/kwalletd/

Will give it a try when I have the time in the next few days but the problem is identical on four different computers.

Let you know.

It still fails as before "host not found..." etc. regardless of version / OS version. There is something fundamentally wrong somewhere, pity it is so hard to find.

I am restarting the client 2-5 times a day to sync, it gives up after a while. In our scenario there are hundreds of thousands of files and perhaps that is too much for it.

Tried command line/cron sync and while it always finishes ok it creates clashes and you are left with conflicts.

Leaving it alone often ends with 100% CPU and nothing happens until killed and restarted.

You cant have it all, can you?

/per

(In reply to peo from comment #29)
Have you tried an equivalent to this with kwalletd?:

> In the end what I did was manually deleting everything related to NC in the keyring file (~/.local/share/keyrings/....keyring), and manually add one by one the NC accounts again to the nextcloud installation.

Given that this was also reported upstream (e.g.: https://github.com/nextcloud/desktop/issues/5466), my guess is that we were unlucky enough to have a buggy version of NC-client insert bogus data in our keyrings, which then confused NC-client on subsequent runs.

Since I did the keyring cleanup, NC has been working flawlessly against multiple servers, I remember this being very frustrating, so if you haven't tried this yet, please do so and report back.

I'm not familiar with kwalletd, but maybe you'd even want to have a small test with a fully empty keyring!