After upgrading oC 7, New shares not syncing

[iliyasbasir]

Expected behavior

We are seeing some inconsistent behavior with syncing shared content after upgrading our servers to ownCloud 7 a little over a week ago. Here are two tests I've run which are typical of the symptoms users are reporting to me.

Test 1:
User A shares a folder with User B. It shows in the web interface for User B but won't sync to their computer (tried with our build of 1.6.4 on Windows 7 and your build of 1.7.1 on Mac OS X 10.9) without manual intervention. Clicking Modify Account and changing username (we can authenticate with upn or samaccount name) or server address (direct vs load balancer) causes the client to do a full discovery phase and syncs the newly shared content. This is required with every new piece of content. Other content syncs fine. If this process is performed on one client the other client starts syncing most of the time, but not all. This could suggest the issue is server side rather than a problem with the client.

If the shares are removed, the content is not removed from remote computers. It is then uploaded by the client as new content and appears in the web interface just as it did before except without showing who shared the content.

Test 2:
With only one client syncing, User A shares a folder with User B again. In this instance the content synced straight away. But when removing the share, the content stayed in the local ownCloud folder but was never synced back to the server a new content. This test was performed connected directly to one web server not the load balancer. Lots of propfinds in the apache logs but the change in content is never detected and the files are never removed from the desktop. Modify account results in the content being uploaded to the server as owned by the "sharee". This breaks the ownership of the files and any permissions that may have been imposed on re-sharing. As the new owner, the share can now share that content with anyone. There are now two copies living on our server.

Test 3:
The previous two tests were performed with the share_folder parameter in config.php set to '/Shared' to continue the behavior of ownCloud 6. We wanted to continue to use this location so that users could use selective sync to block all shared content if they wanted to and just move certain things out of /Shared since you can do that now. We commented out that setting and changes started working exactly as expected with syncing being performed as normal however some previous shared content (but not all) re downloaded to the root level of the account leaving the previous copy in /Shared. The copy in /Shared did not show as shared content in the web interface. Manually deleting this copy and moving the newly downloaded copy from / to /Shared resulted in exactly the same setup as before but with sharing and syncing actually working correctly.

This is a significant security, storage and usability concern. We've had to switch our production system configuration in order to get sharing and syncing working reliably. And this has resulted in shares re-downloading. Which in some cases are quite large. It is clear that this parameter is not being used correctly server side in some way. When this issue is fixed we'd like to be able to switch back to having newly shared content land in /Shared without requiring users to re-download existing shares, wherever they may be within their account.

We've also been chasing down issues relating to duplication of files when renaming or moving. It would appear that this is related to the incorrect sync due to the use of this parameter.

Due to the loss of control of data by the sharer, the lack of deletion of data, the duplication of files, re-downloads, etc, can you please treat this ticket as highest priority. This is a most serious bug in our opinion. There are no errors shown in the logs indicating any kind of failure. It just seems that in some blocks of code that parameter is being used to identify where shared content should go and in other's it isn't.

As a separate but related question, one user reported sharing a folder with another user and then they tried to rename the folder. It shows with the new name in their account (not local and web) but the old name remains in the other users account (both local and web). Files within the shared folder sync between users just fine, it just appears as a different name in the two accounts. Is this a bug or by design and part of the ability to move shared content wherever a user wants? If the latter, that's fine but we need to educate our users on this change.

Actual behavior

Share should work as design

Steps to reproduce

Test 1 , Test 2 & Test 3 above listed

Server configuration

Operating system:centos 6.6

Web server:Apache 2.2.15

Database:

PHP version:5.5.20

ownCloud version:7.0.4

Storage backend:

Client configuration

Client version:

Operating system:

OS language:

Installation path of client:

Logs

Log locataion S3/shares/ownCloud/support/github-issues/core/13868

@MorrisJobke @bboule @LukasReschke

[LukasReschke]

Well, to be honest a large text blob instead of a structured list (i.e. 1. Click foo 2. Click bar 3. It explodes) is not really something that makes developers happy to take a look in their spare-time ;-)

[iliyasbasir]

@LukasReschke :I placed explicitly customer test so developer have clear picture if customer missing /or not performing correct step. Or other way around where our product need improvement.

[PVince81]

Sounds similar to #13333

[PVince81]

This big blob of text seems to mention several separate issues.
Please raise the separate issues / requirements as separate tickets (ex: file duplications).

Also it would help to get the steps in the form of "1. Upload file X in subfolder A, 2. Share A with user2, 3. Login as user2, etc..."

[PVince81]

and let's keep this ticket here only for the "new shares not syncing" issue.

[DeepDiver1975]

We have seen some issues i the area of change propagation on externals storages as well - from my guts feeling this all belongs to the same root cause -> 8.1 topic THX

[iliyasbasir]

@LukasReschke @MorrisJobke @DeepDiver1975 : log added

[craigpg]

@iliyasbasir, can you break this out into discrete issues as suggested by @PVince81?

This big blob of text seems to mention several separate issues. Please raise the separate issues / requirements as separate tickets (ex: file duplications).

Also it would help to get the steps in the form of "1. Upload file X in subfolder A, 2. Share A with user2, 3. Login as user2, etc..."

[iliyasbasir]

@PVince81 @DeepDiver1975
The three tests are different examples to show the process of isolating the issue down to that shared content parameter in config.php being the culprit. Test3 showed that when using the default for this, '/', everything worked as normal.

It would simply be to set that parameter to '/Shared' and then test all sharing and unsharing functions ensuring that syncing with the desktop client works for all changes in all directions.

The entire system of syncing shared content fails when using this parameter.

If you really won’t go with one then pick test #1

Test 1:

User A shares a folder with User B. It shows in the web interface for User B but won't sync to their computer (tried with our build of 1.6.4 on Windows 7 and your build of 1.7.1 on Mac OS X 10.9) without manual intervention. Clicking Modify Account and changing username (we can authenticate with upn or samaccount name) or server address (direct vs load balancer) causes the client to do a full discovery phase and syncs the newly shared content. This is required with every new piece of content. Other content syncs fine. If this process is performed on one client the other client starts syncing most of the time, but not all. This could suggest the issue is server side rather than a problem with the client.
If the shares are removed, the content is not removed from remote computers. It is then uploaded by the client as new content and appears in the web interface just as it did before except without showing who shared the content.

[PVince81]

This sounds similar to #13333 which I cannot reproduce.

Can you try the steps from #13333 (comment) and see whether the etag changes properly ?

Are we talking about simple shares, not reshares and also not group shares ?
Is this a freshly shared folder or one that existed before the upgrade ? If yes, does it happen with new shares ? Have a look at select * from oc_shares where file_target like '%name_of_the_folder_as_seen_by_recipient%'.

[nickvergessen]

Moved it to the right milestone (other one is closed)

[iliyasbasir]

@PVince81 Query run placed at S3/shares/ownCloud/support/github-issues/core/13868

[PVince81]

@iliyasbasir I'd appreciate if you would answer my questions from #13868 (comment) instead of just dumping results.

Also the result you have posted is missing the "parent" column which is supposed to be an id but it says "folder" which is the item_type. It seems the column names are shifted. Having the parent value could help find out whether these are reshares or not.

But the most useful information is the one about etags. If you think the steps are too complex, let me know and I'll try and come up with something quicker.

Thanks.

[PVince81]

I tried the following locally:

1. Setup OC 6 (stable6)
2. Create two users "root" (the admin) and "user1"
3. Login as "user1"
4. Create a folder "test" and share it with "root"
5. Setup the sync client for "root"
6. Wait for sync, "Shared/test" is downloaded
7. Upgrade to OC 7.0.4
8. Notice that the folder "test" is still in "Shared"
9. As "user1" upload some files in "test" in the web UI
10. Wait for sync. Notice that the sync client has downloaded the files.
11. As "user1" create a new folder "test2" with some files and share it with "root"
12. Wait for sync. Notice that the folder appeared under "/Shared/test2"
13. Check config.php: notice that "shared_folder" is already set to "/Shared"

At this point let's simulate the case of the admin who changed that setting.
14) Comment out "shared_folder" in config.php. Wait for sync.
15) As "user1" change files in both "test" and "test2"
16) Wait for sync. The folders are updated properly and staid in "Shared", as expected. (no slippage)
17) As "user1" create a folder "test3" with files inside, share with "root"
18) Wait for sync. As expected the folder now appears in the root as "/test3"
19) Change "shared_folder" back to "/Shared" in config.php
20) As "user1" change the contents of "test", "test2" and "test3"
21) Wait for sync. The sync client properly downloads the files for all.

All seems to work properly.

I don't think they ran into the known upgrade issue from OC 7.0.4 where the update of shares was interrupted / not run properly for LDAP users (assuming they have LDAP... not clear from the report): #14040.

Needs further research.

[PVince81]

As for this guy #13333 (comment), one theory is that the sync client runs into a timeout during the discovery phase, or fails to sync something else and just stops instead of continuing to sync. Let me have a look at your logs.

[PVince81]

@iliyasbasir the logs are quite big. Do you know the name of a share and/or file that was uploaded into the shared folder, one that was not synced ?

In the log I see mentions of GoogleDrive. Is the bug happening for files shared from external storage or from anywhere ?

[PVince81]

Ok, I'll try and look for "CentOS patching" in the logs then.

[PVince81]

Unfortunately I didn't find any clues.

@iliyasbasir can you provide the following information:

1. Pick a share that doesn't sync, I guess "CentOS Patching" is one of them. Run a sync client locally. Modify a file in the share. Wait for sync. According to "Test 1" it would not sync. Please provide the client sync log for that one so we can observe the discovery phase of the client.

2. Pick a shared folder that duplicates itself as per "Test 3". If I understand well, those shares refuse to stay in "Shared" and automatically slip back to the root. Then run the query select * from oc_shares where file_target like '%name_of_the_folder_as_seen_by_recipient%' for that folder. Please put the result in a text file as outputted by the database client (no XLSX this time).
   If the "parent" field is not null, then additionally do a select * from oc_share where id=%share_id_from_parent% and replace the value with the one read from the previous "parent" field. If "parent" is set it means it is a reshare.
   I wonder if they were having the known issue where parent shares weren't maintained properly (Group share + reshare parent inconsistent when child share entry is missing #13361)

Thanks.

[LukasReschke]

No idea why I was assigned to this issue – I have no idea about all this stuff and don't feel like spending days in that 🙈

[bboule]

@iliyasbasir I think @PVince81 has asked some questions that will need some answers specifically we should gather the client side sync logs from this user, and break these tests down and attempt to reproduce, lets have a look at 13361 and see if this fix would have an impact. Lets have a look at this and see if we can move this forward based on @PVince81 last set of comments.

[iliyasbasir]

Hopefully ..issue resolved in 7.0.5

Thank you
-Iliyas