Share folder by link fails when folder is in external storage and storage is restricted to a user group #26916

Closed
tedstrauss opened this Issue Jan 10, 2017 · 23 comments

Projects

None yet

3 participants

@tedstrauss
tedstrauss commented Jan 10, 2017 edited

Cross-posting: https://central.owncloud.org/t/share-folder-by-link-fails-when-folder-is-in-external-storage-and-storage-is-restricted-to-a-user-group/4993

Steps to reproduce

  1. Create new user group Lab_group. Add your own user account, and some other users as members of this group.
  2. Create new external storage instance, type=local, call it Lab_ext_storage in OC > Admin.
  3. Add Lab_group in the section available for for new external storage. This restricts access of storage to the group. [THIS IS THE CRITICAL STEP FOR REPRODUCING THE BUG]
  4. Open advanced settings for Lab_ext_storage (gear icon) and check enable sharing.
  5. Go to OC > Files. Enter Lab_ext_storage folder, add some sample files there.
  6. Go to OC > Files. Open details section for Lab_ext_storage (... button).
  7. In Lab_ext_storage > details > sharing, check 'share link', check 'password protect' and provide a password. Copy the share link.
  8. Open a new incognito browser (or different browser app), paste the share link, and open authentication page. Enter password created in step 7.

Expected behaviour

The shared folder (within the external storage) should open for the anonymous user.

Actual behaviour

Error message: File not found. The specified document has not been found on the server.

Log message: {"reqId":"BrCBE\/JJw2akPaK+IMJm","remoteAddr":"132.206.xxx.xx","app":"filesystem","message":"Storage wrapper 'sharePermissions' was not registered via the 'OC_Filesystem - preSetup' hook which could cause potential problems.","level":2,"time":"2017-01-10T16:41:17+00:00","method":"PROPFIND","url":"\/public.php\/webdav\/","user":"--"}

Screen shot:

screenshot from 2017-01-10 12 49 39

Server configuration
Operating system: Ubuntu 14.04.5 LTS (trusty)
Web server: Apache
Database: MySQL
PHP version: PHP 5.5.9
ownCloud version (see ownCloud admin page): 9.1.2
Updated from an older ownCloud or fresh install: fresh install
Special configuration (external storage, external authentication, reverse proxy, server-side-encryption):

External storage: local storage, local folder mounts NFS drive within local network

ownCloud log (data/owncloud.log)

{"reqId":"BrCBE/JJw2akPaK+IMJm","remoteAddr":"132.206.xxx.xx","app":"filesystem","message":"Storage wrapper 'sharePermissions' was not registered via the 'OC_Filesystem - preSetup' hook which could cause potential problems.","level":2,"time":"2017-01-10T16:41:17+00:00","method":"PROPFIND","url":"/public.php/webdav/","user":"--"}

Integrity status for oC9+

No errors have been found.

@PVince81
Collaborator

Thanks for the detailed report, especially the steps!

@owncloud/qa can you guys confirm this issue ?

@davitol
Contributor
davitol commented Jan 11, 2017 edited

@tedstrauss Thank you so much for the detailed steps!!!

Tested with PHP 5.5.9-1ubuntu4.13 , Ubuntu 14.04.1 LTS trusty, oC 9.1.2, fresh installation.

I CANNOT get the error message

Error message: File not found. The specified document has not been found on the server.

Files shared in the local mountpoint are visible for me.

OOTH the log reported is spotted

{"reqId":"2ds3dJY+iZp\/QWgoH4qZ","remoteAddr":"82.159.139.58","app":"filesystem","message":"Storage wrapper 'sharePermissions' was not registered via the 'OC_Filesystem - preSetup' hook which could cause potential problems.","level":2,"time":"2017-01-11T07:51:31+00:00","method":"PROPFIND","url":"\/public.php\/webdav\/","user":"--"}

@PVince81

@PVince81
Collaborator

This log entry is unrelated and can be ignored.

@PVince81
Collaborator

@davitol apparently he shared the mount point directly, did you do that as well ?

@tedstrauss select * from oc_share where token='omega2' (yes, replace with the share token of the broken share). Then select * from oc_filecache fc, oc_storages s where fc.storage=s.numeric_id and fc.fileid=$filesource and replace $filesource with the value of "file_source" from the previous query.

@davitol
Contributor
davitol commented Jan 11, 2017 edited

@davitol apparently he shared the mount point directly, did you do that as well ?

@PVince81 Yes I did, via link using the details menu I shared the whole mount point

@tedstrauss

ok @PVince81 here are results of those 2 queries.


| id | share_type | share_with                                                     | uid_owner | uid_initiator | parent | item_type | item_source | item_target | file_source | file_target | permissions | stime      | accepted | expiration | token | mail_send |
+----+------------+----------------------------------------------------------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+-------------+-------------+------------+----------+------------+-------+-----------+
| 24 |          3 | 1|$2y$10$mDAfANinvLTDxqU9c1mA3.Ce.m64ByTbQjhaKHch9UF9Vq7Aoh25. | admin     | admin         |   NULL | folder    | 46934       | NULL        |       46934 | /omega      |           1 | 1481750801 |        0 | NULL       | omega |         0 |


| fileid | storage | path | path_hash                        | parent | name | mimetype | mimepart | size         | mtime      | storage_mtime | encrypted | unencrypted_size | etag          | permissions | checksum | id                                 | numeric_id | available | last_checked |
+--------+---------+------+----------------------------------+--------+------+----------+----------+--------------+------------+---------------+-----------+------------------+---------------+-------------+----------+------------------------------------+------------+-----------+--------------+
|  46934 |      18 |      | d41d8cd98f00b204e9800998ecf8427e |     -1 |      |        2 |        1 | 180815842304 | 1484074133 |    1484074133 |         0 |                0 | 58752c957e559 |          23 |          | local::/var/www/owncloud/meg-data/ |         18 |         1 |   1484150621 |

@PVince81
Collaborator

Hmm, that looks correct.

Can you check the "oc_storages" table and see if this "meg-data" you posted is the only "local::" entry with that path ? (no duplicates)

One reason for a broken link is sometimes that the file is located on the wrong storage in the DB.

@tedstrauss

I can confirm that there are no duplicates of that path in the oc_storages table.

@tedstrauss

Just to repeat from above: The bug appears when I add a user group to the 'Available for' section of the External storage share. When I remove the group and refresh the share URL, the content loads fine.
What DB tables are affected by entering something in the 'Available for' field? I could generate queries for those with and without a value there. It could help?

@PVince81
Collaborator

I don't think it's relevant, but as I'm out of ideas let's try anyway: check the tables oc_external_applicable, oc_external_config, oc_external_mounts, oc_external_options

@tedstrauss
tedstrauss commented Jan 11, 2017 edited

Ok, reporting highlights from those tables.
Here are values from oc_external_applicable table for the given share, first before adding the group share, next after added the group share, and last reverting back to no share.

Question: What affect does the type field have?

| applicable_id | mount_id | type | value      |
+---------------+----------+------+------------+
|            25 |        9 |    1 | NULL       |

... share external:local with 'available for' group ...

|            26 |        9 |    2 | neuroSPEED |

... unshare external:local ... 

|            27 |        9 |    1 | NULL       |

Here are the entries from the oc_external_config, oc_external_mounts, oc_external_options tables for the share.

select * from oc_external_config;

| config_id | mount_id | key     | value                         |
+-----------+----------+---------+-------------------------------+
|         6 |        9 | datadir | /var/www/owncloud/meg-data/   |

select * from oc_external_mounts;

| mount_id | mount_point                 | storage_backend | auth_backend | priority | type |
+----------+-----------------------------+-----------------+--------------+----------+------+
|        9 | /omega                      | local           | null::null   |      150 |    1 |

select * from oc_external_options;

| option_id | mount_id | key                      | value |
+-----------+----------+--------------------------+-------+
|        31 |        9 | encrypt                  | true  |
|        32 |        9 | previews                 | true  |
|        33 |        9 | enable_sharing           | true  |
|        34 |        9 | filesystem_check_changes | 1     |
|        35 |        9 | encoding_compatibility   | false |

@PVince81
Collaborator

Regarding the type:
possible mount types: global = 1, group = 2, user = 3

Oh, you have encryption. I overlooked that.
But then you're getting a 404 not found, not an encryption key error.

Ok, let me have a quick local try on my own env.

@tedstrauss

I really appreciate the help!

@PVince81
Collaborator

I tested both with v9.1.3 from git and tarball, could not reproduce the issue.

But this gave me an idea: usually the share link page would return 404 when the sharing user is not allowed to access the file, when it is basically an invalid link.

Does the page first asks you for the password before showing the error or does the error appear directly ?

Can you post a screenshot of your "Sharing" section of the admin page ? Maybe you ticked some boxes there like "Restrict users to only share with users in their groups" or others. And if yes, maybe the sharing code is confused about permissions there.

@tedstrauss
tedstrauss commented Jan 11, 2017 edited

It does ask for the password first, yes. And the error page appears after entering the password. If I remove the external group share and refresh that page, it then loads.

Here is the sharing dialogue you requested:
image

And the sharing details for the individual folder:
image

@PVince81
Collaborator

the error page appears after entering the password

Hmm, so this means it's not treated as invalid link, else you'd see the error page first.
So that tells us something is wrong in a logic further down the road.

Your sharing options look standard, so possibly unrelated.

What is this "Share link: rename" button ? Do you have any third party apps enabled that could interfere with shares ?

@tedstrauss
tedstrauss commented Jan 11, 2017 edited

Here is a list of all OC apps that are currently enabled. Highlighted a couple that seem relevant.

Official: activity, collaborative tags, comments, default encryption module, deleted files, external sites, external storage support, federation, first run wizard, gallery, LDAP user and group backend, Mail template editor, notifications, PDF viewer, provisioning API, share files, text editor, update notifications, versions, video player

Non-official: documents, activity defaults, AppOrder, Files Share link renamer, log reader, piwik tracking.

@davitol
Contributor
davitol commented Jan 11, 2017

Files Share link renamer

@tedstrauss Can you try to disable Files Share link renamer app and repeat the steps of the issue? Thanks in advanced

@PVince81
Collaborator

and maybe also "piwik tracking" in case it's hooking into the link share system and interfering

@tedstrauss

Ok i'm getting some promising but inconsistent results in toggling the Files Share link renamer app. Will continue testing, and looking for a place to share the bug with the app developer.

@tedstrauss

The bug has been worked-around by disabling the link-renaming feature on the share.
The Files Share link renamer app and Piwik app are still enabled, but the feature is now turned off for this particular share. I will post a report about this to the app developer and then close this ticket.

Thanks everyone for your help!

@PVince81
Collaborator

@tedstrauss thanks. If you find information about what the app is doing wrong it would be interesting to know.

I suspect that maybe it is using hacks to hook into the code in a way that influences the result.

@PVince81 PVince81 closed this Jan 11, 2017
@tedstrauss

The issue has now been reposted here: fcturner/sharerenamer#13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment