Permission issues in shared folder

[yaleokali]

I am having an issue with permissions in shared folders. I have 2 users, userA and userB. With userA I create a folder called "test" which I share with userB with the following permission: “create" but not the other three ("update", "delete" and “share”).

Expected behaviour

I expect userB to be able to add a file in the folder created and shared by userA, both through the web interface and the desktop client.

Actual behaviour

On the web interface, when I add a file with userB to the shared folder, the file appears without any icon and as having a size of 0. If I refresh the page, the file is no longer there.
On userA web interface, the file never appears.
Then I try to sync from the desktop client from userB a file added in the share folder, the client returns an error in the “synchronization information” tab.

Steps to reproduce

1. Create 2 users, userA and userB for example
2. From userA web interface, create a folder and share it with userB, giving him “create” permissions (and no others)
3. From userB, try adding a file to the previous folder

Server configuration

Operating system: Linux
Web server: Appach
Database: MySQL
PHP version: 5.3.24
ownCloud version: 5.0.9

Client configuration

Browser: Chrome 28 or Internet Explorer 10 (both totaly up to date)
Operating system: Windows 7 (totaly up to date

Logs

ownCloud log (data/owncloud.log)
Warning PHP Undefined index: mime at /home/content/17/9197417/html/owncloud/apps/files/ajax/mimeicon.php#3 23.07.2013 13:17:23
Warning PHP Undefined index: mime at /home/content/17/9197417/html/owncloud/apps/files/ajax/mimeicon.php#3 23.07.2013 13:00:42
Warning PHP Undefined index: mime at /home/content/17/9197417/html/owncloud/apps/files/ajax/mimeicon.php#3 23.07.2013 13:00:04
Error search_lucene need mimetype for content extraction 23.07.2013 12:59
Warning PHP Undefined index: mime at /home/content/17/9197417/html/owncloud/apps/files/ajax/mimeicon.php#3 23.07.2013 12:57
Warning PHP readdir() expects parameter 1 to be resource, boolean given at /home/content/17/9197417/html/owncloud/lib/cache/file.php#89 23.07.2013 12:57
Warning PHP opendir(/home/content/17/9197417/html/owncloud/data/test2/cache/) [function.opendir]: failed to open dir: No such file or directory at /home/content/17/9197417/html/owncloud/lib/files/storage/local.php#40 23.07.2013 12:57
Warning search_lucene failed to extract meta information for /test/files/Testing: Could not open "/home/content/17/9197417/html/owncloud/data/test/files/Testing" (does not exist, or is not a file) 23.07.2013 12:55
Warning PHP readdir() expects parameter 1 to be resource, boolean given at /home/content/17/9197417/html/owncloud/lib/cache/file.php#89 23.07.2013 12:55
Warning PHP opendir(/home/content/17/9197417/html/owncloud/data/test/cache/) [function.opendir]: failed to open dir: No such file or directory at /home/content/17/9197417/html/owncloud/lib/files/storage/local.php#40 23.07.2013 12:55
Warning PHP mysql_close(): 46 is not a valid MySQL-Link resource at /home/content/17/9197417/html/owncloud/lib/setup.php#284 23.07.2013 12:46

[DeepDiver1975]

@MTGap

[yaleokali]

Giving the "update" permission unlocks everything ofcourse, but that isn't what we would need...

[MTGap]

Can edit is a combination of create, update, and delete permissions. You shouldn't have that one checked for what you're trying to do.

[yaleokali]

Hello. Thanks for your reply.
I cannot select "create" and not "edit" (unselecting "edit" unselects "create". Selecting "create" selects "edit")...

[MTGap]

Well then you must have all three of create, update, and delete already selected. Deselect update and delete.

[yaleokali]

I do exacly that, I just leave "create" selected (and "edit" as it cannot be unselected when "create" is selected), and userB cannot add anything.

On the windows client, in the synchronization information, the file I create with userB in the folder shared by userA (with "create" permission given to userB) appears in the error list and is not synchronized (userA doesn't see it in the folder on the web interface for example).

[MTGap]

Now I see, that's a user interface bug.

[yaleokali]

Ah okidoki. So it should be solvable ?

[yaleokali]

Could you tell me where I should start looking in order to correct this bug ?
Looking at network I think that the sharing I want is currently coded as " 5 " in the ajax request sent to core\ajax\share.php
Is that where the bug is (should be an other number sent ?) or is the bug somewhere else ?
Regards.

[MTGap]

It's somewhere in here: https://github.com/owncloud/core/blob/master/core/js/share.js#L507

[yaleokali]

could https://github.com/owncloud/core/blob/master/core/js/share.js#L104 be related as well ?

[MTGap]

Nope, that's unrelated.

[yaleokali]

Well, so far I haven't found anything.
That code is more advanced than anything I've dug into, but I just don't see what the problem could be there ^^

[ghost]

If you look at the AJAX request to upload.php when you upload the file, it is the same with create or create and update permissions set.
Create permission is correctly set when you change the permission of a folder, because it gives number five ( 1 for edit + 4 for create).
In upload.php I've found this line that is weid for me... maybe that's why it doesn't work ?
https://github.com/owncloud/core/blob/master/apps/files/ajax/upload.php#L26

[yaleokali]

Yes, the interface is sending the create permissions : 5 properly I think (at least it looks similar to the permissions : 3 that is sent for update 3 = 2+1 for update + read)
So what I don't understand is where the interface bug is when setting the permissions...
To me, it feels like the bug is more related to what is happening when a file is uploaded, but I could very well be wrong...
All I know is that I was unable to find something wrong around https://github.com/owncloud/core/blob/master/core/js/share.js#L507 so far...

[yaleokali]

I've had a look in the MySQL database and userB does have permissions : 5 for the given folder in the "oc_share" table. So apparently, the table is correctly updated. This value does change properly when I modify the permissions (adding update for example...)
So if there is a user interface bug, wouldn't it rather be on the interpretation of the permissions when you add a file rather than when setting the permissions ?

[MTGap]

I'm lost with your investigation. At this point you should fill out the template, because I don't understand where the problem is anymore: https://github.com/owncloud/core/blob/master/issue_template.md

Do you not see the option to upload files in the shared folder or does the upload not work?

[yaleokali]

On userB webinterface, I do see the option to upload files in the shared folder, however, the upload does not succeed. (no icon, size of 0, and the file disapears when I reload the page).
If I try to do it from the desktop client, I am unable to successfully synchronize.

I've updated the first post according to the template to help you better understand and eventually try to reproduce if you can find the time for it.

Thanks a lot for your help

[MTGap]

Sorry, about that. It seems we've both been wasting our time.

Can you disable the search_lucene app and retry
Can you check the permissions on your data directory. @bartv2 any other ideas about why the cache is failing, besides permissions?

[yaleokali]

I am not sure what the search_lucene app is, it doesn't appear in my app list.
I've disabled the app named "Full Text Search" as it sounded like the closest thing to it. It did not solve the problem... (so I've enabled it again just in case)
Is that the one that you wanted me to disable ?

My data directory has 770 permissions.

Thanks

[MTGap]

Yes, that's the correct app. I'm not sure what's going on, but something is most likely wrong with your webserver configuration. Waiting for any suggestions from @bartv2.

[yaleokali]

OK. So you don't have the same issue on your installation ?
If that's of any help, I am hosted by godaddy.com ...

[yaleokali]

I've tested it on an other webhosting solution I pay (OVH) and I have the same problem on it aswell...

[yaleokali]

And I've just tried it on my computer using WAMP, same problem there too...
@MTGap @bartv2 Is it working properly on your webserver ?
Thanks

[bartv2]

@crearaintl Am I correct that userA is named test and userB is named test2? And that uploading with userA to that folder just works?
@MTGap the logging from search_lucene indicates that it expects the file to be /test/files/Testing, maybe it is dropping a folder somewhere?

Also the the caching is not related to this problem, the error comes from the garbage collector function

[yaleokali]

@bartv2 yes, you are correct on all aspects.

[yaleokali]

I though of something and I don't base my reflection on any facts, as I'm not a pro on that kind of maters...

Could it be that php way of uploading files creates a an empty file and then fills it with content ? In which case since the "update" permission is turned off, it is unable to put the content inside, resulting to an error...

Might be totaly wrong :p

[yaleokali]

@MTGap @bartv2
I still haven't found a way to solve the problem, so I guess that until you pro guys discover where it is from and correct it, I'll twick the user interface a bit in order to check both [create] and [update] when ever one is checked, and uncheck both when even one is unchecked. Not a fix, just a way to hide the bug. Won't work the way I wanted it to, but haven't found anything that could do it, so... ^^
Rgds

[PVince81]

According to the PR, this should be fixed already. Please try again with OC 5.0.13 or OC 5 master.

Feel free to reopen if it still occurs for you in the recent versions.
Thanks.