Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sharing deleted after update from 7.0.4 to 8.0.2 #15304

Closed
etiess opened this issue Mar 30, 2015 · 10 comments
Closed

Sharing deleted after update from 7.0.4 to 8.0.2 #15304

etiess opened this issue Mar 30, 2015 · 10 comments
Labels

Comments

@etiess
Copy link

etiess commented Mar 30, 2015

Steps to reproduce

  1. User A shares Folder1 with GroupA
  2. GroupA members (including User2) have access to Folder1
  3. User2 moves Folder1 into his personal Folder2
  4. Everything is fine, modifications are shared accross all users
  5. Update to 8.0.4

Expected behaviour

Shared folder should remain shared

Actual behaviour

Sharing is removed, Folder1 is removed from User1 and all other Group1's members
OC Client removes Folder1 from their disk too
User1 still has Folder1 but not shared anymore

Server configuration

Ubuntu 14.10
3.16.0-33-generic
Server version: Apache/2.4.10 (Ubuntu)
PHP 5.5.12-2ubuntu4.3 (cli) (built: Mar 16 2015 20:50:26)
mysql Ver 14.14 Distrib 5.5.41, for debian-linux-gnu (x86_64) using readline 6.3

ownCloud version: (see ownCloud admin page) 8.0.2

Updated from an older ownCloud or fresh install: 7.0.4

List of activated apps: Standard

Are you using external storage, if yes which one: No
Are you using encryption: no

Are you using an external user-backend, if yes which one: No

I saw some issues which looks similar but not sure if they are related:

@karlitschek
Copy link
Contributor

@schiesbn

@PVince81
Copy link
Contributor

@etiess are there any reshares involved ?

If I understand well, User 2 only moved the mount point "Folder 1" into an own "Folder 2".

AFAIK there is no code that would touch/migrate/affect the share information during the upgrade.
Can you confirm that none of the users did any other operations on the share after the update ?
Did the sharing information disappear directly after the update ?

How old is the original share, was it created before 7.0.2 ?
Since it's a group share, maybe the group share entries were broken for some reason.

Do you have a backup of the database where you could check the matching share info in oc_share ? Just to see how it looks like before the upgrade.

@etiess
Copy link
Author

etiess commented Apr 10, 2015

@PVince81 You're right. UserA shared Folder1 with the group. He did not do anything related to this folder. I don't think User2 did anything either. But all other GroupA members lost access to Folder1. I cannot say exactly when it appeared, it was a few days after the update that I noticed it.

I don't know exatcly when the original share was created, but it was done End of December 2014. It was still shared on February 20th. And server updates were done shortly after their release (except for 7.0.4 -> 8.0.2 which was done later to wait for a stable release).

I do have a backup of the database that I did just before the update to 8.0.2. But I'm unfortunately not very skilled to look into it: if it's not to complicated, and if it worth it for you, could you explain me what exactly I should look at, and how to do that. Alternatively, I could give you access to it.

@PVince81
Copy link
Contributor

I tried the following locally:

  1. Setup OC 7.0.4
  2. Create three users "user1", "user2", "user3"
  3. Add "user2" and "user3" in a new group "groupa"
  4. User1 creates a folder "Folder1", uploads a few pics
  5. User1 shares "Folder1" with "groupa"
  6. User2 moves "Folder1" into "Folder2"
  7. Upgrade to 8.0.2
  8. Check the shared folder

This still works.

Now if you say that the sharing info got lost, this reminds me of the cases where the fileid changes.
Continue with the following:
9. Create a user "user4"
10. User4 creates a folder "Target" and shares it with "User1"
11. User1 moves "Folder1" into "Target"

At this point the folder's fileid will change because it is moved cross-storages (shared storage) and the share info gets orphaned.

This should hopefully be fixed soon by #15360

Let's find out if that's what happened in your environment.
Please check your current database: select * from oc_share where not exists (select fileid from oc_filecache where item_source = fileid). This will return all orphaned shares.
One of them should have the "uid_owner" set to "User1" and the "share_with" set to "Group1".

Maybe User1 moved Folder1 into another share by mistake then moved it back ?

@PVince81
Copy link
Contributor

This is the actual ticket that describes how file ids can get lost/changed: #13310 (comment) (share information is linked to the fileid, so losing it would lose the share)

@etiess
Copy link
Author

etiess commented Apr 10, 2015

This is the result of the command you indicated:
share

@etiess
Copy link
Author

etiess commented Apr 10, 2015

The shared folder is called "Famille", GroupA includes User1 User2 User3 and User4.

@PVince81
Copy link
Contributor

Right, that must be it. And I guess "Perso" and "Documents" are Folder2 where the recipients moved their files.

The fact that you got this results shows that indeed the share got lost due to fileid change. Now not sure if User1 maybe at some point moved "Famille" into another share locally, then maybe moved it back after noticing their mistake. That could cause the filelid loss.

You might want to run select * from oc_filecache where fileid=357972 too. That's the file cache entry the share was pointing to. I think that one might be gone/non-existing.

@etiess
Copy link
Author

etiess commented Apr 10, 2015

Right: "no data returned"

@PVince81
Copy link
Contributor

Ok, so this confirms that the issue is related to a fileid change, which will be fixed by #15360 (in upcoming 8.1)

@lock lock bot locked as resolved and limited conversation to collaborators Aug 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants