You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some deleted shared sub-folders are systematically recreated by another user. Some other folders can be deleted.
I notice that on an instance with a group of about 20 users hosted on a server with high CPU load average. And also on another server with no load, and less than 10 users.
This occurs only with Windows users.
When looking at history of this file, only "creation" is logged.
When looking at databases operations, we can see successively:
deleted_self by User A
created_self by User B
Everything looks like normal operations, as if User B have really created a new folder.
Steps to reproduce
A folder shared with a group of users
User A deletes a folder
Few seconds later, User B re-create this same folder
Expected behavior
Nextcloud-client does not recreate deleted folders or files.
Which files are affected by this bug
No error in server logs
Operating system
Windows
Which version of the operating system you are running.
Windows 10
Package
Other
Nextcloud Server version
24.0.7
Nextcloud Desktop Client version
3.6.4
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 3.4.2 to 3.4.4)
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 error appears in logs when this occurs.
Additional info
Both instance are with PostgreSQL database, not sure there is a link, but in case.
I see these threads, but no solution neither workaround:
I have the same Problem which I can reproduce at least for two Folders. User A delets the Folder. A minute later User B creates the folder again. I can repeat that game as often as I want. Everything shows up in the Activity Log. After some time not only the folder itself but all of its sub structure with other folders / files is back. In this game even users who have definitely no desctop sync client running show up as creators! I'm just a user on our system, so unfortunately I can't provide logs or additional help.
In this game even users who have definitely no desctop sync client running show up as creators!
Very strange!
Today I notice, for a user who always recreate a folder, that "Last connection" is one month old (when looking at users list in https://cloud.domain.tld/settings/users). But this user is connected with its nextcloud-client right now, I can see it in Apache logs and its desktop config. Maybe another problem (and another issue to open), but in case it could help…
I definitely have no error logs from server. I will collect desktop logs from this user, and hope something is logged.
Bug description
Some deleted shared sub-folders are systematically recreated by another user. Some other folders can be deleted.
I notice that on an instance with a group of about 20 users hosted on a server with high CPU load average. And also on another server with no load, and less than 10 users.
This occurs only with Windows users.
When looking at history of this file, only "creation" is logged.
When looking at databases operations, we can see successively:
deleted_self
by User Acreated_self
by User BEverything looks like normal operations, as if User B have really created a new folder.
Steps to reproduce
Expected behavior
Nextcloud-client does not recreate deleted folders or files.
Which files are affected by this bug
No error in server logs
Operating system
Windows
Which version of the operating system you are running.
Windows 10
Package
Other
Nextcloud Server version
24.0.7
Nextcloud Desktop Client version
3.6.4
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 3.4.2 to 3.4.4)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
Nextcloud Server logs
No error appears in logs when this occurs.
Additional info
Both instance are with PostgreSQL database, not sure there is a link, but in case.
I see these threads, but no solution neither workaround:
The text was updated successfully, but these errors were encountered: