Desktop: Version 2.5: Client does not sync/The server file discovery reply is missing data

[klada]

I have installed version 2.5.0 of the Desktop Client (Windows, completely fresh install) and the client does not sync at all. I am getting the following sync error right after going through the configuration assistant:

A HTTP transmission error happened. The server file discovery reply is missing data.

The requests on the server look fine, I am getting many PROPFIND requests there, all answered with HTTP 207.

:warning: Version 2.3.3 of the client is working fine on the very same machine with the very same user. → regression

Expected behaviour

The sync process should start after configuration.

Actual behaviour

The sync fails immediately after configuration (fresh config, fresh installation, empty sync dir).

Steps to reproduce

1. Install and configure client (clean/fresh install)
2. Sync fails immediately

Client configuration

Client version: 2.5.0

Operating system: Windows 10 (x64)

OS language: English/German

Server configuration

Operating system: CentOS 7.5

Web server: Apache 2.4.6-80

Database: Postgres

PHP version:7.2.12

Nextcloud version: 14.0.3

Storage backend (external storage): -

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)

https://gist.github.com/klada/fd88210850c4f4ec783c9e837a622acb

1. Web server error log:

(there are no errors)

192.168.12.16 - otto [13/Nov/2018:11:06:26 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 399 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:06:38 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 400 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:06:56 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 399 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:07:10 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 400 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:07:26 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 399 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:07:42 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 400 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:07:56 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 399 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:08:14 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 400 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:08:26 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 399 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:08:46 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 400 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:08:56 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 399 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:08:58 +0100] "GET /ocs/v2.php/apps/notifications/api/v2/notifications?format=json HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 0
192.168.12.16 - otto [13/Nov/2018:11:09:18 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 400 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:09:26 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 399 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:09:50 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 400 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1
192.168.12.16 - otto [13/Nov/2018:11:09:56 +0100] "PROPFIND /remote.php/dav/files/otto/ HTTP/1.1" 207 399 "-" "Mozilla/5.0 (Windows) mirall/2.5.0v2.5.0 (build 20181112) (Nextcloud)" 1

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

Not applicable.

[klada]

This seems to be the relevant part of the client log:

[OCC::LsColJob::finished    LSCOL of QUrl("https://mycloud.local/remote.php/dav/files/otto/") FINISHED WITH STATUS "OK"
[OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot     Missing properties: "test" 2 0 1542103459 "DNVS" "" "-0000001ocrvl2k5jw23"
[csync_ftw  opendir failed for  - errno 10011
[OCC::SyncEngine::handleSyncError   ERROR during  csync_update :  "Es hat sich ein HTTP-Übertragungsfehler ereignet. Bei der Server-Dateierkennungsantwort fehlen Daten."

What is interesting is the Missing properties part. Apparently an ETAG is missing for the file or directory "test". The check which is failing has been introduced by 687b6f5655, which explains why the client version 2.3.3 is working fine.

The strange part is that the user does not have a directory or file with the name "test" in his user folder. I have already tried running occ files:scan for the user, but this did not change anything.

BTW: In Client version 2.3.3.1 I am getting this warning:

11-13 13:49:20:680 8260 OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot: WARNING: etag of test is   This must not happen.

In version 2.3.3 this was a warning and in version 2.5.0 this is now an error which stops the entire sync.

[merlinschumacher]

Same issue for me on Arch Linux

[rullzer]

This seems more like a server issue. But even then it is weird.

There is of course a good reason that the client refuses to sync if it gets back things it can't make sense of from the server. Because it can't make sense of what is happening.

I assume it only happens for both of you on some accounts and not on all?

[klada]

Yes, it's probably a server issue. It still triggers a regression in the client:

• Version 2.3.3 is working fine
• Version 2.5.0 is not working at all → regression

And you are right, I can only reproduce the issue with one user account. Other user accounts are working fine with version 2.5.0. The strange part is that I have tried a occ files:scan, but it does not solve the issue.

@merlinschumacher Do you have a line like this in your client log?

[OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot     Missing properties: "test" 2 0 1542103459 "DNVS" "" "-0000001ocrvl2k5jw23"

If yes, what does the "Missing properties" message say? Does it mention a filename you recognize?

[nliautaud]

Same here, caused by a bug in Google Drive external storage extension. Removing or updating the extension eliminated the client error.

OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot  Missing properties: "GoogleDrive"

Note that the 2.3.3 client version was working even with this server extension issue.

[merlinschumacher]

The Gdrive-Plugin is indeed the issue. After installing a newer version from the app-store sync works fine.

[tofuSCHNITZEL]

I have a similar issue. But I don't have the Gdrive Plugin installed and all other Plugins are up to date.

[OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot Missing properties: "Fotos Tauschrausch" 2 0 1542792323 "DNVS" "" "-0000001oc90bef3ea20"
[csync_ftw opendir failed for - errno 10011

the above mentioned folder is not visible in the webclient - but it appears in the "select files/folders to sync dialog" and even if it is not checked the above error appears.

in the oc_mounts and oc_shares table an entry exists for this folder. I removed the entry and now the client syncs again.

[messimuc]

I had a similar issue. As I am just a user I cannot post logs. Some other user shared a folder with me, at some point this other user got deleted but her shared folder stayed in my files view. Client 2.3.3 had no issues, Client 2.5 stopped working: "A HTTP transmission error happened". Deleting the shared folder solved the issue for me.

[r2evans]

Same symptom, for me it was an external share that could not connect (the remote end is shut down for a bit). I don't know that it's always the problem (nor if SFTP is the only culprit), but when I disabled the external share the error went away and normal syncing resumed.

[klada]

In my case it's also a stale share causing the issue. Pretty much like @tofuSCHNITZEL described it:

• In my case is a share named "test" (see log in post 2)
• I see this share in the WebUI under "Shares", but not in "All Files".
• I see this folder in the sync client properties
• When I exclude this folder from syncing the sync client is working

[seanbaker74]

I have the same issue. I had set up a CIFS/SMB external storage that was "broken" due to a configuration issue on my part. Until I fixed the external storage, my NextCloud client sync was failing with the "server file discovery reply is missing data" error message. Seems pretty easy to reproduce.

[mlanner]

It seems that the "external storages" server component that was changed in the 14.x series caused this bug, as I reported here:

https://github.com/nextcloud/server/issues/11264

[r2evans]

@mlanner, we might be talking about something different. My server is still on 13 (not stated earlier, but it now appears to be more of a server-bug than a client-bug).

[nathanael-h]

I had the same problem on ArchLinux, I tried to delete my old non working external storages (SFTP I did not use anymore) and it worked.
Server is 14 on Debian

[mioiox]

Server NC13, client NC 2.51. I am using a bunch of SMB folders (the SMB server is Windows Server 2019, but is shouldn't matter). All folders are accessible except one (that is physically missing on the server at the moment). However, when I start syncing any of the fine folders, I get the same error. I managed to clear it by removing the bad folder from the NC configuration and the sync started without error.

However, I would expect to be able to sync the folders that are OK, as issues with one folder should not impact the sync capability of any other folder.

[ghost]

Same here I guess.

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

[bjoernv]

Now I see this bug too:

nextcloud 14.04 (with PHP 7.2 on Ubuntu 14.04)
nextcloud-client 2.5.1git (openSUSE Tumbleweed)

I do not have external storage except another Nextcloud 15.0.0 server which is connected with this Nextcloud server.

[bjoernv]

I was able to analyze my "The server file discovery reply is missing data." error message which stopped client synchronization because the error is thrown in the discovery phase before the synchronization phase.

I had two problematic files (one file, one directory). Unfortunately I have only partial logs. I used the --logfile nc.log --logdebug options.

I changed the file and directory names for privacy reasons. The server send this message for the file: Please note the trailing slash for the file "20150727_myexcelfile KVP20150820.pptx/". This is a normal Powerpoint file and should not have a trailing slash.

  <d:response>
    <d:href>/nextcloud/remote.php/dav/files/myusername/20150727_myexcelfile KVP20150820.pptx/</d:href>
    <d:propstat>
      <d:prop>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
        <oc:size>0</oc:size>
        <oc:permissions>SGDNV</oc:permissions>
        <oc:fileid>-1</oc:fileid>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>

The NC client complained:

[OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot     Missing properties: "20150727_myexcelfile KVP20150820.pptx" 2 0 1547298781 "DNVS" "" "-0000001oc2khb5drj3s"
[OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot     Missing properties: "200 MyDirectory" 2 0 1547298781 "DNVS" "" "-0000001oc2khb5drj3s"
[csync_ftw  opendir failed for  - errno 10011
[OCC::SyncEngine::handleSyncError   ERROR during  csync_update :  "Es hat sich ein HTTP-Übertragungsfehler ereignet. Bei der Server-Dateierkennungsantwort fehlen Daten."
[OCC::ActivityWidget::addError  Item  "/var/home/myusername/nextcloud"  retrieved resulted in  "Es hat sich ein HTTP-Übertragungsfehler ereignet. Bei der Server-Dateierkennungsantwort fehlen Daten."

The directory "200 MyDirectory" exists in the filesystem, but only in files_versions and files_trashbin. The file 20150727_myexcelfile KVP20150820.pptx exists as a normal file.

I checked the file and directory in the NC database and removed the entries in oc_filecache. After that I started the command "./occ files:scan --all".

Now NC client 2.5.1 synchronizes again. I have to wait for the next problem to analyze the problem further. I also did not checked, if NC client 2.3.3 would also have stopped on the problematic files. I would guess, that NC client 2.3.3 was more fault tolerant here so that this problem comes up with NC 2.5.1. But also with NC client 2.3.3 I had problems with files, which were in oc_filescache but not in the filesystem.

[harcesz]

same problem, tested o 2-3 stations, good thing, we havent upgraded all our clients yet...

a simple workaround for ubuntu/linux is to use the 3.3 appimage; https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.3.3-x86_64.AppImage

[heyarne]

My problem was a folder shared with me by a person that no longer existed. I removed the folder and sync is working again.

[aaronSkar]

Had a similar issue with a file that showed up with as examplefile.ext/ rather than examplefile.ext it also was mounted in incorrect spots. I deleted all entries for the file in oc_mounts and oc_filecache and sync works again.

Note this issue came about after a migration from a snap deployment to a docker deployment in my case.

[gerroon]

I had the same issue, which was caused by a missing path to a share. However it would have been nice if it throws the error and syncs the initial folders

[Thoro]

Agree, the error message could at least contain the path to the folder which is the issue, for non-IT users absolutely impossible to figure out ...

[pachevalier]

Same error on Ubuntu Mate. What is the trick ?

[Thoro]

Start the client with --logwindow then check what folder is there, and then try to figure out where the folder comes from.

For me it was a unshared / shared folder, only visible in the "Shared" section of the website.

[a-schild]

I see the same problem here, with the GoogleDrive external storage no longer supported in NC 15.x
I'm not able to remove the invalid (unknown) external storage type

[averi]

Same problem here with no external storage plugin installed, what we observed when using LDAP as backend is that whenever a specific user was removed from the LDAP group authorized to access the instance it broke the desktop client as it was trying to sync a directory that was bound to an inactive user, the fix here was either to remove the share manually from oc_share and oc_mounts OR extend the LDAP groups that could access the instance including the one that had former members.

[tofuSCHNITZEL]

Yes this is exactly my situation! I'm spit balling here but, maybe it has something to do with an issue I noticed with the function getGroupsByMember (and subsequently walkNestedGroups) in https://github.com/nextcloud/server/blob/master/apps/user_ldap/lib/Group_LDAP.php

As far as I could test and understand it the function does not work with LDAP implementations that don't use an entity's DN for the membership attribute (I believe like openLDAP where it is the uid)

unfortunately I didn't have the resources yet to devise a fix, also I'm lacking an LDAP where the DN is used as the membership to test it further

[denics]

If this can help, I confirm that the same thing happened to me installing sharepoint backend.

[marcelklehr]

@blizzz Can you take a look at this?

[nonbinary]

I'm having a similar problem, but with a federated share. The server with the problem has moved behind a firewall, but has a share from a public server. The user on the hidden server cannot remove the federated share, and cannot sync with the shared folder there.
Disabling file sharing does solve the problem temporarily, but the server needs that functionality...

[blizzz]

It sounds like there are two possible causes:

1. unresolvable shares. And this can have a different issue if you are on 16 (fix → https://github.com/nextcloud/server/pull/15399). For the LDAP part, if there are server logs ideally with exceptions, that would be lovely.
2. external storages, with different backends. also here, please look out for server logs.

[PetrVladimirov]

It sounds like there are two possible causes:

1. unresolvable shares. And this can have a different issue if you are on 16 (fix → [nextcloud/server#15399](https://github.com/nextcloud/server/pull/15399)). For the LDAP part, if there are server logs ideally with exceptions, that would be lovely.

2. external storages, with different backends. also here, please look out for server logs.

1 for me, just SMB with no LDAP (nextcloud 15).

[blizzz]

@IvanKazak could you enforce this error to happen and provide the resulting nextcloud.log file?

[PetrVladimirov]

@IvanKazak could you enforce this error to happen and provide the resulting nextcloud.log file?

@blizzz here are the steps to reproduce and nextcloud log:

1. Connected a SMB share from scratch (Host=pure IP; user/pass auth) via web-console; made it avaivalble for user _test_
2. Logged in via desktop client with user _test_ + ensured that the share was available (folder syncing was unchecked)
3. Stopped SMB share
4. Openned nc desktop client (was running OK in the backgroun with green light icon) and tried to expand the share - application crashed & was closed by windows
5. Started nc desktop client - got the error "A HTTP transimission error happened. The server file discovery reply is missing data."
   
   6.nextcloud.log is attached
   nextcloud-1.log

[blizzz]

@IvanKazak There is an error related to SMB: stream does not support seeking at

Please update to latest NC 15 as there were some SMB related fixes since 15.0.5

[vpecinka]

Same for me - NC 15.0.8, LDAP, when somebody leaves company and left shares, those unresolvable shares causes desktop sync client stop as mentioned above. Removing the share solves problem (but is unfriendly).

[InfamousUser]

Same error here...

Edit: Disappeared the next day.

[InfamousUser]

I wonder if this has anything to do with unreachable external storage, obviously it shouldn't since you can't expect everything to be available at every given point.

[sblaisot]

I can confirm the behaviour with desktop client 2.5.2git (build 20190319) and nextcloud server 16.0.1 with LDAP authentication.
Removing a user from LDAP server leads to broken sync if the removed user had shares. Removing the shares manually from the database fix the sync (i.e. delete from oc_share where uid_owner='<internal id of removed user>).

[Pisoko]

At our school we run into this issue more often.
Is there a way to find out which deactivated account coursing this problem?
Currently the only way to fix this is to downgrade from 2.5 to 2.3. :(

[sblaisot]

@pisoko your (server) log will tell you which user is not available anymore.
Upgrading nextcloud server to 16.0.3 resolved the issue for me.

[kyhuynhduc]

same with NC 16.01
client : 2.5.3

[FreeMinded]

Upgrading nextcloud server to 16.0.3 resolved the issue for me.

Not for us! Problem still exists with NC 16.0.3 with LDAP users, Group Folders and Sync Client 2.5.2 on OSX

[llucax]

Having the same issue here. I went through a data recovery process because the HDD where the nextcloud data directory died (but the MySQL DB was in another HDD and survived). I only had an almost 1 year old backup of the data directory and restored that. I'm not sure if some inconsistency between the old data directory and the new DB is causing this or not, but I also don't know which file/directory is causing the issue.

Is there any way to debug this more in depth? I have external (local) data storage configured but the user with the problem (I have this problem only with one user, although this is a home server with just 4 users) has no access to it (it had before but I disabled it just to be sure external storage is not the issue).

[llucax]

Also, when accessing to the user's file via Web, all seems normal, but accessing via Nextcloud desktop client (Mac, old version which doesn't get this error), I see folder names that are not shown in the web, which are like the external storage folders with a " (2)" appended. I think before the data crash they were shared by some other user.

Is there any way to clean the shares DB to make sure that's not interfering?

[llucax]

I found these ghost shares. I have 3 shares that appear in the user to whom the folders where shared but not in the user that shared them. They were all external storage directories that were removed and re-created. Is there any way to remove these ghost shares manually poking the DB directly or something?

[llucax]

I removed the share entries from the oc_share table and that fixed the error. The user with whom the directories where shared still get the "Share (2)" file listed in the Desktop client though, I don't know where in the DB are these orphaned files/directories. They are definitely not in the data directory.

[llucax]

I found the dangling references in oc_mounts. Removing those completely removed the ghost directories. I hope I didn't break my nextcloud installation in the long run :).

[kbalicki]

Same issue here. The problem was the external LAN share drive, where IP changed and NextCloud lost connestion to it. After fixing (in Nextcloud dashboard) problem with NExtCloud App sync stopped.

[ccoenen]

I just ran into this, I since updated my client (now 2.5.3), my Nextcloud server (now 16.0.4) and I truncated the oc_filecache table and did occ files:scan for each user. (see note at the end of the post) The problem persists.

I don't have any external storage configured.

In my client log, I have these:

[OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot     Missing properties: "Protokolle" 2 0 1566201198 "DNVS" "" "-0000001oc48bcl52l0z"
[OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot     Missing properties: "Bilder TEst" 2 0 1566201198 "DNVS" "" "-0000001oc48bcl52l0z"

Which were both shared with my by another user (which is a regular local user that still exists, no external storage involved). I removed these shares an I still have the same problem, but now with three different Directories shared with me.

I am now completely out of ideas. Can anyone help me get this back on track?

__Note: I do not recommend going about it this way. I may have lost all my shares this way__

__Note 2: My only remedy was restoring from a backup 2-3 days earlier.__

[gvansanden]

I don't have any external storages also, but I notice that NC seems to treat groupfolders as external storage...
Still having the bug on 16.0.4

[gvansanden]

I manage to get sync back.
The problem was that I moved a shared subdirectory that was mounted under /shared/ to a groupfolder. The sharing moved with it. Even when I deleted the content, it still stayed shared. So I removed the mounts from oc_mounts, I removed the directory from the groupfolders/trash on the filesystem and it's refrerences from oc_fileshare. And sync works again..

Quite nasty

[lp4]

I had the same issue and just fixed it. Here's what I did:

I had no 3rd party Google Drive plugins or anything, so I ended up unsharing a bunch of shares (via the web UI) from the account that wasn't synchronizing properly. I noticed my shared group was not working correctly, so I just unshared everything associated with that group. I saw one other shared directory that was broken, so I unshared it as well. I kicked off a re-sync everything is working again! Doing it this way I have no worries that I broke something on the backend that I'll notice in 6 months.

[misch7]

Did you try our recent 2.6 release?
https://nextcloud.com/install/#install-clients

Perhaps the issue has been solved in the meantime.

[lp4]

Yes, I tried it on PC and Mac before messing with the shares. No dice. :(

By the way I'm on NC v15.

At first i thought it had something to do with me forcing TLS 1.3, so i migrated back to 1.2. Further troubleshooting brought me here.

[misch7]

@lp4 Thanks for the update.

Just a side note:
TLS 1.3 works from client version 2.6 and up on Windows. On Linux it will work from 2.6.1 with our AppImage or if your distro supports >= Qt 5.12.4 and OpenSSL 1.1.1

Mac is in progress and we hope to include TLS 1.3 there in 2.6.1 too :)

[brunt82]

Same like #908 ?

[gvansanden]

@brunt82 #908 has a different cause AFAIK, I get it on files in groupfolders that have been put in trash.

[brunt82]

@brunt82 #908 has a different cause AFAIK, I get it on files in groupfolders that have been put in trash.

Of couse there are many causes for problems while syncing. Anyhow the client should not prevent syncing completly (see first post). Instead it should report the error, ignore the folder and continue with next.

I assume that most of the described problems are server issues, which cannot be fixed on client side. Therefore it should be implemented any kind of error handling... but in my eyes the client should not stop working because of an erorr of one folder.

See also blizz comment: https://github.com/nextcloud/desktop/issues/819#issuecomment-489798474_

[fcmildef]

We are experiencing similar problems, turns out user A had shared folders with user B, then they either got removed renamed or moved (still trying to find out) , but they still persist in the database.
In user B in the webinterface "shared with you" I still see the old folders, trying to open them gives a operation not perrmitted.

edit: user A moved said folders into a group folder that user B was also member of. looks like nextcloud didnt properly remove the orignal shares from the database

[gvansanden]

@fcmildef That is because they remain in trash. I've stopped using groupfolders, regular shared folders don't seem to have the same issue

[fcmildef]

That is not an option for us. This looks like a bug in nc server and I think it could be fixed
Any other workarounds you have in mind?

[gvansanden]

@fcmildef I'm not sure there is a bug in NC itself connected to it. The folders in Trash are still there so shares still exist. The cause AFAIK is that groupfolders don't behave exactly like normal folders do, which isn't a problem in core but rather in groupfolders. The main issue is that I've seen so many problems with groupfolders and syncing that I suspect that combination doesn't get a lot of testing.

[denics]

Did you check if your dav folders are correctly exposed? otherwise you'll have to follow the doc and manipulate your .htaccess

[fcmildef]

@denics Im sorry I dont follow, could you elaborate?

[fcmildef]

btw @gvansanden I found 3 of the 4 folders in the trash of user A, I deleted them permanentely so now theres only one folder that the client complains about, but I can not find it anywhere, except for in the database.

[misch7]

We recently merged a fix addressing the HTTP Transmission Error issue and it's included in our 2.7 Beta 1:
https://github.com/nextcloud/desktop/releases/tag/v2.7.0-beta1

Could you give it a try and see if this solves the problem?

I'd recommend to test the Beta with another user or on a test machine. Alternatively you may start the nextcloud.exe with the parameter --confdir <path> to specify another configuration folder.

[brunt82]

I tested the beta client with following configuration:
User A has a share folder and a share file from an user B, which does not exist anymore in LDAP. The old client (2.6.2) displays the error message "HTTP transmission error" immediately after configuring the client to connect with user A.

The new client (2.7.0 Beta 1) seems to work normally. The synchronisation works with the same user, no error message appears. But anyway there is a faulty behavior: In attached screenshot you see the file "test.png" although this file has been shared by the deleted user. The file is marked as folder (German: "Dateiordner") in windows file system. It is possible to browse into (it's empty) without any error message.
The shared folder of the deleted user had not be synchronized.

[misch7]

@brunt82 Thanks for testing and reporting! :-)
Then I'll happily back-port the fix for the upcoming 2.6.3 release.

The other issue with the file appearing as a folder is actually pretty weird. I couldn't even imagine how this could happen upon creation since there should be two completely different system calls invoked for file vs. folder creation. But at least the sync is working again so far now.

[brunt82]

By the way: The client crashes if I expand the shared folder of the deleted user within the client settings (inside the menu where to select to folder for synchronization). But this occurs also with the current client (2.6.2) - so this seems no "new" issue.

[wouterVE]

@misch7
I have the same problem as @brunt82 :

The admin user shared a (external) folder called Algemeen Sales with the users belonging to the dept of sales. I later renamed the external folder to Algemeen SALES. Now I see in the client the two folders. The old one (Algemeen Sales) with a size of 0 bytes. When I try to expand the folder, the desktop client crashes.
I see the same error as the OP (A HTTP transmission error happened. The server file discovery reply is missing data) and the synchronisation stops.
I tried to update the client to 2.6.4, but it makes no difference. I downgraded tot 2.3.3 and now I still see the ghost folder Algemeen sales, but the client does sync again and does not crash when I expand the folder. It shows an error:
an error occurred while loading the list of folders from the server. Error transfering https://cloud.example.com/remote.php/dav/files/user/Algemeen Sales/ - server replied: fo..

Here is the relevant log entry for client 2.6.4

[OCC::DiscoverySingleDirectoryJob::directoryListingIteratedSlot     Missing path to a share : "Algemeen Sales" "Algemeen Sales" 2 0 1583312380 "DNVS" "" "-0000001oct3tct3f1ya"
[csync_ftw  opendir failed for  - errno 10011
[OCC::SyncEngine::handleSyncError   ERROR during  csync_update :  "Une erreur de transmission HTTP s'est produite. Donnees manquantes dans la reponse a decouverte du fichier sur le serveur "
[OCC::ActivityWidget::addError  Item  "Nextcloud"  retrieved resulted in  "Une erreur de transmission HTTP s'est produite. Donnees manquantes dans la reponse a decouverte du fichier sur le serveur "
[OCC::ActivityListModel::addErrorToActivityList     Error successfully added to the notification list:  "Une erreur de transmission HTTP s'est produite. Donn饳 manquantes dans la reponse a decouverte du fichier sur le serveur "

In client version 2.3.3 it is only mentioned in one line:

`03-04 10:03:52:094 0x6d1bb04 csync_walker: directory: Algemeen Sales [file_id=-0000001oct3tct3f1ya]

I didn't test beta version 2.7 but as I understand the fix is backported to 2.6.x so it would not make an difference.

Thus, as far as I can tell, the http transmission error is not fixed yet. Hopefully you can do something with the listed logs.
(fyi: I installed the different clients on the same pc, but wipped the client config in %appdata%)

[misch7]

@wouterVE
Thanks for the detailed report! 👍

This is really helpful for further investigation. I think I've to find a way to trigger the same error for debugging.
Perhaps @brunt82's hint with the deleted user may help me, I remember to have read this as a cause for the HTTP Transmission Error somewhere too.

[wouterVE]

@misch7
You are welcome! If in need for further info please feel free to ask.
FYI: my Nextcloud is version 17.0.3

[Derkades]

Sync Client 2.6.4 / Nextcloud 18.0.3

Happened to me when one of my external storages was unavailable because of missing smb client. After installing the package it immediately started syncing again.

[Linutux]

I have had the same error. I had an old mount point pointing to a Openstack storage, which did not work. It showed as a red folder in the web file interface and could be deleted at the moint point config of my user. After removing it, the sync client synced again.

[Fuseteam]

i can confirm removing an unreachable external storage resolves this issue in my case

[InfamousUser]

Great! Please fix the message to say so in case of external storage issue.

[leotulipan]

Just wanted to leave my comments here. Had this exact problem with client 3.0.3 (Win10) on a Nextcloud installation with 20.0.1.1

With the tips here I started the client on the command line with

"C:\Program Files\Nextcloud\nextcloud.exe" --logwindow --logdebug

which brought me to these two lines:

2020-11-15 09:33:38:311 [ warning nextcloud.sync.discovery ]: Missing properties: "plenty_ftp" 2 0 1605429216 "M" "" "-0000001ocfvc8lpdbsi"
2020-11-15 09:33:38:312 [ debug nextcloud.sync.discovery ] [ OCC::DiscoveryMainThread::singleDirectoryJobFinishedWithErrorSlot ]: 10011 "In der Antwort der Server-Dateierkennung fehlen Daten."

That ftp/sftp external storage had problems with the username/password. What is frustrating, I actually de-selected this in the folder-synchronisation selection but it still stops ANY sync from happening.

A better fall-back would be to skip (external) folders with missing properties so the sync can still continue for all the rest.
Also it would be really helpful to actually output the warning in the standard GUI and not the message following it about missing data, as that is really not useful to find the error

[much-doge]

Just wanted to leave my comments here. Had this exact problem with client 3.0.3 (Win10) on a Nextcloud installation with 20.0.1.1

With the tips here I started the client on the command line with

"C:\Program Files\Nextcloud\nextcloud.exe" --logwindow --logdebug

which brought me to these two lines:

2020-11-15 09:33:38:311 [ warning nextcloud.sync.discovery ]: Missing properties: "plenty_ftp" 2 0 1605429216 "M" "" "-0000001ocfvc8lpdbsi"
2020-11-15 09:33:38:312 [ debug nextcloud.sync.discovery ] [ OCC::DiscoveryMainThread::singleDirectoryJobFinishedWithErrorSlot ]: 10011 "In der Antwort der Server-Dateierkennung fehlen Daten."

That ftp/sftp external storage had problems with the username/password. What is frustrating, I actually de-selected this in the folder-synchronisation selection but it still stops ANY sync from happening.

A better fall-back would be to skip (external) folders with missing properties so the sync can still continue for all the rest.
Also it would be really helpful to actually output the warning in the standard GUI and not the message following it about missing data, as that is really not useful to find the error

got the same issue, i had to delete the sync connection in the admin panel(external storage section) for the error to go away. the error message should be clearer