Domain user cannot access files via Web or Client, or WebDAV - Invalid recipient

[turin13]

Steps to reproduce

1. Try to login as one of the affected users (currently 5 such users)
2. Get Internal server error upon successful login with Remote Address (user's IP) and Request ID
3. Get error in the owncloud.log (see below)

Expected behaviour

Normal login and access to the files

Server configuration

Operating system:

Ubuntu 14.04 x86_64

Web server:

Apache/2.4.7 (Ubuntu)

Database:

MySQL Distrib 5.5.53, for debian-linux-gnu on x86_64

PHP version:

PHP 5.5.9-1ubuntu4.20
Zend Engine v2.5.0

ownCloud version: (see ownCloud admin page)

ownCloud 9.1.2 (stable)

Updated from an older ownCloud or fresh install:

Update from previous major version (done several tymes)

Where did you install ownCloud from:

Ubuntu repository (deb)

Signing status (ownCloud 9.0 and above):

No errors have been found.

List of activated apps:

Enabled:
  - activity: 2.3.2
  - comments: 0.3.0
  - dav: 0.2.7
  - federatedfilesharing: 0.3.0
  - files: 1.5.1
  - files_antivirus: 0.9.0.0
  - files_pdfviewer: 0.8.1
  - files_sharing: 0.10.0
  - files_texteditor: 2.1
  - files_trashbin: 0.9.0
  - files_versions: 1.3.0
  - firstrunwizard: 1.1
  - gallery: 15.0.0
  - notifications: 0.3.0
  - provisioning_api: 0.5.0
  - systemtags: 0.3.0
  - templateeditor: 0.1
  - updatenotification: 0.2.1
  - user_ldap: 0.9.0

The content of config/config.php:

{
    "system": {
        "updatechecker": false,
        "instanceid": "ID",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
			DOMAINS
        ],
        "datadirectory": "\/var\/www\/owncloud\/data",
        "overwrite.cli.url": "http:\/\/URL\/owncloud",
        "dbtype": "mysql",
        "version": "9.1.2.5",
        "dbname": "DB",
        "dbhost": "localhost",
        "dbtableprefix": "PREFIX",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "logtimezone": "UTC",
        "installed": true,
        "memcache.local": "\\OC\\Memcache\\APC",
        "mail_smtpmode": "smtp",
        "mail_smtphost": "HOST",
        "mail_smtpport": "25",
        "mail_from_address": "EMAIL",
        "mail_domain": "DOMAIN",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "tls",
        "ldapIgnoreNamingRules": false,
        "loglevel": 3,
        "maintenance": false
    }
}

Are you using encryption:

No

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

ActiveDirectory

Logs

ownCloud log (data/owncloud.log)

Exception: {"Exception":"InvalidArgumentException","Message":"Invalid recipient","Code":0,"Trace":"
#0 /var/www/owncloud/apps/files_sharing/lib/MountProvider.php(171): OC\Share20\Manager->moveShare(Object(OC\Share20\Share), '6C3E62C1-82F4-4...')
#1 /var/www/owncloud/apps/files_sharing/lib/MountProvider.php(76): OCA\Files_Sharing\MountProvider->buildSuperShares(Array, Object(OC\User\User))
#2 /var/www/owncloud/lib/private/Files/Config/MountProviderCollection.php(76): OCA\Files_Sharing\MountProvider->getMountsForUser(Object(OC\User\User), Object(OC\Files\Storage\StorageFactory))
#3 [internal function]: OC\Files\Config\MountProviderCollection->OC\Files\Config\{closure}(Object(OCA\Files_Sharing\MountProvider))
#4 /var/www/owncloud/lib/private/Files/Config/MountProviderCollection.php(77): array_map(Object(Closure), Array)
#5 /var/www/owncloud/lib/private/Files/Filesystem.php(440): OC\Files\Config\MountProviderCollection->getMountsForUser(Object(OC\User\User))
#6 /var/www/owncloud/lib/private/Files/Filesystem.php(370): OC\Files\Filesystem::initMountPoints('6C3E62C1-82F4-4...')
#7 /var/www/owncloud/lib/private/legacy/util.php(226): OC\Files\Filesystem::init('6C3E62C1-82F4-4...', '/6C3E62C1-82F4-...')
#8 /var/www/owncloud/lib/base.php(890): OC_Util::setupFS()
#9 /var/www/owncloud/index.php(54): OC::handleRequest()
#10 {main}","File":"/var/www/owncloud/lib/private/Share20/Manager.php","Line":862}

[PVince81]

moveShare is only called whenever a duplicate share entry was found when the FS is setup.

For example is a user is receiving two shares with the name "test", at the time ownCloud sets up the filesystem it will rename one of the received shares to "test (2)" by calling moveShare.

@turin13 can you provide more information about the sharing scenario for the affected users ?
Maybe one of the sharers or recipients of such folder doesn't exist any more.

[turin13]

@PVince81 Thank you for the reply.
How can I check all user's shares if I couldn't login as that user? I hope there's the other way than checking all other users and their shares.

[PVince81]

Check oc_ldap_user_mapping table to find the ownCloud ID (a long hash) of the affected users.

Then do a select * from oc_share where share_with in (...) or uid_owner in (...), replace "..." with a comma separated list of user ids

[turin13]

I did the examination as you suggested.
I checked all 5 affected users. 2 of them have nothing shared with them at all and 3 others have different shares and tey looks normal.
But later I check something - one of the affected users have no entry in oc_mounts table. May this be relevant? When I do sudo -u www-data php occ file:scan on the ID of that user I get this:

**Exception while scanning: Invalid recipient**
#0 /var/www/owncloud/apps/files_sharing/lib/MountProvider.php(171): OC\Share20\Manager->moveShare(Object(OC\Share20\Share), '6C3E62C1-82F4-4...')
#1 /var/www/owncloud/apps/files_sharing/lib/MountProvider.php(76): OCA\Files_Sharing\MountProvider->buildSuperShares(Array, Object(OC\User\User))
#2 /var/www/owncloud/lib/private/Files/Config/MountProviderCollection.php(76): OCA\Files_Sharing\MountProvider->getMountsForUser(Object(OC\User\User), Object(OC\Files\Storage\StorageFactory))
#3 [internal function]: OC\Files\Config\MountProviderCollection->OC\Files\Config\{closure}(Object(OCA\Files_Sharing\MountProvider))
#4 /var/www/owncloud/lib/private/Files/Config/MountProviderCollection.php(77): array_map(Object(Closure), Array)
#5 /var/www/owncloud/lib/private/Files/Filesystem.php(440): OC\Files\Config\MountProviderCollection->getMountsForUser(Object(OC\User\User))
#6 /var/www/owncloud/lib/private/Files/Filesystem.php(370): OC\Files\Filesystem::initMountPoints('6C3E62C1-82F4-4...')
#7 /var/www/owncloud/lib/private/legacy/util.php(226): OC\Files\Filesystem::init('6C3E62C1-82F4-4...', '/6C3E62C1-82F4-...')
#8 /var/www/owncloud/lib/private/Files/Utils/Scanner.php(82): OC_Util::setupFS('6C3E62C1-82F4-4...')
#9 /var/www/owncloud/lib/private/Files/Utils/Scanner.php(156): OC\Files\Utils\Scanner->getMounts('/6C3E62C1-82F4-...')
#10 /var/www/owncloud/apps/files/lib/Command/Scan.php(158): OC\Files\Utils\Scanner->scan('/6C3E62C1-82F4-...')
#11 /var/www/owncloud/apps/files/lib/Command/Scan.php(226): OCA\Files\Command\Scan->scanFiles('6C3E62C1-82F4-4...', '/6C3E62C1-82F4-...', false, Object(Symfony\Component\Console\Output\ConsoleOutput), false)
#12 /var/www/owncloud/3rdparty/symfony/console/Command/Command.php(259): OCA\Files\Command\Scan->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#13 /var/www/owncloud/core/Command/Base.php(158): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#14 /var/www/owncloud/3rdparty/symfony/console/Application.php(844): OC\Core\Command\Base->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 /var/www/owncloud/3rdparty/symfony/console/Application.php(192): Symfony\Component\Console\Application->doRunCommand(Object(OCA\Files\Command\Scan), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/owncloud/3rdparty/symfony/console/Application.php(123): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /var/www/owncloud/lib/private/Console/Application.php(146): Symfony\Component\Console\Application->run(NULL, NULL)
#18 /var/www/owncloud/console.php(102): OC\Console\Application->run()
#19 /var/www/owncloud/occ(11): require_once('/var/www/ownclo...')
#20 {main}

[turin13]

Any updates, guys? I think I provided the info. If something else is needed just let me know.
Thanks.

[PVince81]

Line 826 is here: https://github.com/owncloud/core/blob/v9.1.2/lib/private/Share20/Manager.php#L862
And the moveShare is called when grouping the shares here: https://github.com/owncloud/core/blob/v9.1.2/apps/files_sharing/lib/MountProvider.php#L171

Some things that we can deduce from this information:

• the user is receiving the share through a group share
• the user is likely receiving the share also through either another group share or another direct user share
• the different shares have different "file_target" entries in the database, which used to be a bug in previous versions that should auto-repair through this very routine in MountProvider
• the repair that makes "file_target" consistent doesn't seem to work here because moveShare refuses to rename the share target because the user in question is not a member of the group from which the user is receiving the share ?!

So maybe the user received a share directly and also through a group and then later was removed from that group.

[PVince81]

I tried to reproduce a similar situation but couldn't.

This is because for some reason when fetching the user's received shares, my env doesn't return the group shares for groups in which the user does not belong to any more.

Somehow on your env it seems that there is an inconsistency: the API fetches all received shares including some group shares where the user doesn't belong in the group any more. Then when trying to group these shares to display only a single received folder, it tries to normalize the target folder name but fails because a check finds out that the user is not in the group share's group any more.

I'm now thinking of a possible quickfix that prevents fixing file_target for group shares in this specific routine.

[PVince81]

Hmm, I looked a bit in the LDAP code.

What I observed is that:

1. The user's group membership in the sharing code is retrieved with groupManager->getUserGroups() which itself goes to LDAP's Group_LDAP::getUserGroups()
2. When verifying if we can rename/move a group share, we check if the user belongs to it using another method groupManager->inGroup() which itself goes to LDAP's Group_LDAP::inGroup().

Now from what I see the LDAP code is slightly different in both methods.
I wonder if it could produce a situation where maybe the cache still says that a user belongs to the group but the other cache/approach says the user is not member any more.

From what I see the cache key is different for both, one starts with "inGroup" the other with "getUserGroups". So there is a slight chance that both caches are telling a different story and causing this weird inconsistency.

[PVince81]

Now here I really wonder why inGroup() isn't simply using getUserGroups(). Maybe some LDAP servers do not support retrieving a user's group memberships and only allow checking inGroup ??

@jvillafanez do you know anything about this ? Is there an easy way to clear the LDAP caches ?

@owncloud/ldap

[PVince81]

Raised owncloud/user_ldap#30 to clarify the general issue for this code inconsistency.

[PVince81]

@turin13 I see you have a memcache set up. Also browsing through the LDAP code shows that the cache it uses is also memcache. So it is likely that there is an inconsistency about group membership in the cache.

Are you able to clear the memcache ? (not sure how, I have no experience with it)