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

tedstrauss opened this Issue Jan 10, 2017 · 23 comments


None yet

3 participants

tedstrauss commented Jan 10, 2017 edited


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":"","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":"","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.


Thanks for the detailed report, especially the steps!

@owncloud/qa can you guys confirm this issue ?

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":"","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":"--"}



This log entry is unrelated and can be ignored.


@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 and fc.fileid=$filesource and replace $filesource with the value of "file_source" from the previous query.

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


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 |


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.


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


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?


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 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 |


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.


I really appreciate the help!


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 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:

And the sharing details for the individual folder:


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 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 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


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


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.


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!


@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

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