UPDATED: Clients stuck on syncing removed folder. Folder visible in web interface, not existing in data folder (OC10.0.2, OCC2.2.3)

Expected behaviour

Sync all folders correctly from client to server and from server to clients.

Actual behaviour

Clients does not sync reliable. We got red marked errors in the first tab of the client(s). All messages try to say that it is impossible to sync a specific file or folder. If i check if the concerning folder exists on the server over the web interface, i can see the folder but if i click on it, i will be redirected to the root again.

I checked if the folder exist in the data folder on the server but is does not. I know that this folder is removed on the desktop of one of my colleagues. So it seems to be that her client has noticed the server to remove the folder, and the server removed it from the data folder. Why i can still see the folder (but cant open) in the web interface, i dont know. I think this is also the problem why the clients cant sync. The clients are stuck on syncing this folder which results in the fact that the rest of the data is also not synced anymore.

My colleague did also some general folder structure changes (in the folder structure below the "main"/root folders). She did also some folder renames. i'm not 100% sure about this (as the clients are not working) but i think we have a similar problem with these files/folders. I can and will test this a bit more after the first problem is solved.

Is the "removed folder problem" a known issue? and can someone help me to solve this problem?
I recently updated to OC10 from 9.1.6? which dit not solve my problem. The clients are also all up-to-date.

Server configuration

Operating system:

Web server: Apache 2
Database: MySQL
PHP version:
ownCloud version: 10.0.2

Client configuration

Client version: 2.3.2 (all of them)
Operating system: Centos 6.x (thought 6.8)
OS language: EN
Qt version used by client package (Linux only, see also Settings dialog):
Client package (From ownCloud or distro) (Linux only):

Installation path of client:

If i'm checking https://owncloud.org/changelog/desktop/ it looks to me that you're not using a recent version on your clients but rather a quite outdated one. It might be possible that this is either a part of your current problem or the main reason for it.

Which error does the client report?

Could be related to https://github.com/owncloud/core/issues/28018

@ Tom42
I'm pretty sure that we use the most recent client version (2.3.2), at least on all Windows pc's. I can check monday if the macbooks also use the most recent version, but as they are just 2 months old and freshly installed, they should be the latest version i think.

I will come back to this.

I did not see this article before but i seems something similar. I will post some logs at monday :slight_smile:. Normal client logs are okay i guess?

@Tom42, i checked all clients today and they are all 2.3.2 (also for iOS) so this can not be the problem.

I uploaded the logs to dropbox for error message: C"Sync could not get access to //path/ as i can not upload things and i always got the message "new users can not post more that 2 links"

@rodo Ok, so then you might want to fix this typo :slight_smile: in your initial post:

Sorry, my bad, its updated!

I read the topic from @guruz and it could be a similar problem. I think the filecache is broken or inconsistent? I also found this:
https://doc.owncloud.org/server/9.0/admin_manual/configuration_server/occ_command.html#file-operations which describes this:

 files:cleanup              cleanup filecache
 files:scan                 rescan filesystem
 files:transfer-ownership   All files and folders are moved to another
                            user - shares are moved as well. (Added in 9.0)

I can try the files:scan, i guess this can not break something. I also think i need to run the files:cleanup but i'm not sure if i can break something with it and make it worse or lose some data. Maybe someone can tell me if it is safe to run these commands without losing data or making my problem worse. If we can not solve this somewhere this week, we will switch to another cloud service which will cost a lot of work and time so i want to avoid this!

If I understand correctly, the bugfix releases coming out will repair this issue?

Yes i understand it also like that but the question is when the bug fix is coming and if it also fixes already broken installations. We can't wait to long as we use Owncloud for our company and we are running into trouble because of the mis-synchronization.

If the above commands can fix the problem for now till the bug fix is released would be great!

AFAIK it might also need the repair steps mentioned in https://github.com/owncloud/core/pull/28253

If an occ files:scan --all doesn't fix your issue then you'll need the repair step from https://github.com/owncloud/core/pull/28253.

Today i installed OC server 10.0.3.x which should contain a fix for the bug which produced my problem so i tried to fix the broken entries in the filecache.
I tried:
- occ files:scan --all
- occ files:scan --all --repair (found here: https://github.com/owncloud/core/pull/28253#issuecomment-322719256) but command is not recoginzed. I did "occ upgrade" before!
- occ maintenance:repair

both without succes. I also read: https://github.com/owncloud/core/pull/28253 but do not understand which steps you mean i should follow? Maybe can you explain this in a bit more detail?

I executed select
fc.fileid, fc.path, fc2.fileid, fc2.path from oc_filecache fc, oc_filecache fc2 where fc.parent = fc2.fileid and CONCAT(fc2.path, '/', fc.name) != fc.path and fc2.path != ''
on the database and have 14 results (should be 0?)

How can i fix my filecache as i do not know how to continue now...

As i was not able to fix this problem, we moved from Owncloud to Office 365 with Sharepoint.
For me is this case closed.