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

Upgrade oc v4.5.8 => v5.0.x: filesystem cache and file sharing problems #2721

Closed
kneiser opened this issue Apr 4, 2013 · 3 comments
Closed

Comments

@kneiser
Copy link

kneiser commented Apr 4, 2013

After upgrading (none of this happens on an oc v5.0.x point update):

  1. User logs in, does not any of their own files (blank) or see folders of other oc users.
  2. If folder(s) from other users, current user cannot navigate in those folders.
  3. Looking at the oc forum shows common recommendation is to "truncate" or "delete all" records from the OC file cache table. This action introduces a severe side effect.
  4. After file cache table is emptied user logs in again and sees their own folders/files.
  5. However now any individually shared files between other oc users are gone. Individual file sharing has to be reset up.
  6. Additionally any folders that were shared via a security group are also gone. Security group still in tack. Sharing folders by security group has to be reset up.
  7. This set of problems for basic oc functionality will not encourage current oc users/organizations to move from prior oc release streams to oc v5.0.x.
@BernhardPosselt
Copy link
Contributor

@icewind1991

@kneiser
Copy link
Author

kneiser commented Apr 25, 2013

Recently I tested V5.0.5 to see what the current situation is for upgrading from v4.5.10 to V 5.0.5. I found that "some" things had changed but not enough of a difference to move to using V5.0.x in a production setting.

  1. Installed V5.0.5 to test machine.
  2. Restored the last point release data from v4.5.10 backups, per owncloud documentation for upgrades.
  3. Logged in to owncloud admin account, owncloud did it's maintenance mode stuff successfully.
  4. The data contains sharing information by individual file(s) and by security group for a set of test users.
  5. Rebooted server.
  6. The admin user sees shared folders from other users, but, admin user is not a member of any sharing. An
    attempt to navigate in to one of the folders results in no action.
  7. Logged in to a normal user where only external storage is defined, no membership as in item 4.
  8. Normal user can access external storage fine, but other folders belonging this user are not visible.
  9. Logged in to test user accounts, no shared files or folders are visible. Sharing busted.
  10. OC forum seems to recommend truncation of the oc_filecache table to resolve this above.
  11. Table emptied and server rebooted.
  12. admin user no longer sees foreign folders. Good.
  13. The "normal user" now has its owned folders back and external storage still works.
  14. One of the test users that is a member of individual file sharing scenario has the files now visible. But there is a
    note at the top of the screen indicating "no write permissions".
  15. One of the test users that is a member of sharing folder by security group still does not have sharing access.
    Again there is a note at the top of the screen about "no write permissions".
  16. Are there any workarounds for this or is this a bug still to be worked on? Also is this "no write permissions"
    something new or does it also relate to the sharing problem?

@kneiser
Copy link
Author

kneiser commented May 21, 2013

Just finished testing and upgrade from v4.5.11 to v5.0.6. Again, I found that "some" things had changed but not enough of a difference to move to using V5.0.x in a production setting.

  1. Installed V5.0.6 to test machine.
  2. Restored the last point release data from v4.5.11 backups, per owncloud documentation for upgrades.
  3. Logged in to owncloud admin account, owncloud did it's maintenance mode stuff successfully.
  4. The data contains sharing information by individual file(s) and by security group for a set of test users.
  5. Rebooted server.
  6. The admin user sees shared folders from other users, but, admin user is not a member of any sharing. An
    attempt to navigate in to one of the folders results in no action.
  7. Logged in to a normal user where only external storage is defined, no sharing membership as in item 4.
  8. Normal user can access external storage fine, but other folders belonging this user are not visible.
  9. Logged in to test user accounts, no shared files or folders are visible. Sharing busted.
  10. OC forum seems to recommend truncation of the oc_filecache table to resolve this above.
  11. Table emptied and server rebooted.
  12. admin user no longer sees foreign folders. Good.
  13. The "normal user" now has its owned folders back and external storage still works.
    READ CAREFULLY FROM HERE: Change since I last reported from v5.0.5
  14. Using test user accounts. Some users setup to share directory by security group. Other test users setup to share by link or by individual files.
  15. File sharing by link: Test user sees "No permissions to write here.". Click on shared file and gets error, "Th file requested cannot be loaded".
  16. Sharing by Security Group: Test user sees "No permissions to write here.". Navigate in to "Shared" folder. Shared directory appears as a text file and not a folder.
  17. Sharing by File: Test user sees "No permissions to write here.". Files appear as text documents not their native file type ( odf, odt).

This is somewhat of an improvement over the last release. However it is getting to be annoying that we have to keep truncating the oc_filecache table after an upgrade. I also noticed that old tables from the prior v4.5.x release still exist.

Why is sharing busted when before the cache table is emptied. Shouldn't the sharing information be stored in separate tables from the cache table?

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

No branches or pull requests

2 participants