Core: App DAV Update on master failed: Exception: Sharing backend for file not found

[blizzz]

Steps to reproduce

1. Have a master instance lying around for some time
2. Pull
3. update
   

   Expected behaviour

Dav Update does not throw exception on missing sharing backend, ownCloud stays functional.

Actual behaviour

Exception thrown, update page looks doubtful (says upgrad was unsuccessful), ownCloud however is functional. It is unclear whether the migration was completed for all users, or it just stopped (i assume so). Doing the upgrade again only states "ownCloud is already latest version
". Backtrace:

{"reqId":"ZLLaVNCObDG3qcAcAOqC","remoteAddr":"127.0.0.1","app":"core","message":"Exception: {\"Exception\":\"Exception\",\"Message\":\"Sharing backend for file not found\",\"Code\":0,\"Trace\":\"
#0 /srv/http/dev/master/lib/private/share/share.php(1658): OC\Share\Share::getBackend('file')\
#1 /srv/http/dev/master/lib/private/share/share.php(336): OC\Share\Share::getItems('file', NULL, -1, 'zombie_530', NULL, -1, NULL, -1, false)\
#2 /srv/http/dev/master/lib/public/share.php(123): OC\Share\Share::getItemsSharedWithUser('file', 'zombie_530', -1, NULL, -1, false)\
#3 /srv/http/dev/master/apps/files_sharing/lib/mountprovider.php(54): OCP\Share::getItemsSharedWithUser('file', 'zombie_530')\
#4 /srv/http/dev/master/lib/private/files/filesystem.php(451): OCA\Files_Sharing\MountProvider->getMountsForUser(Object(OC\User\User), Object(OC\Files\Storage\StorageFactory))\
#5 [internal function]: OC\Files\Filesystem::OC\Files\{closure}(Object(OCA\Files_Sharing\MountProvider))\
#6 /srv/http/dev/master/lib/private/hooks/emittertrait.php(98): call_user_func_array(Object(Closure), Array)\
#7 /srv/http/dev/master/lib/private/files/config/mountprovidercollection.php(87): OC\Files\Config\MountProviderCollection->emit('\\OC\\Files\\Confi...', 'registerMountPr...', Array)\
#8 /srv/http/dev/master/apps/files_sharing/appinfo/application.php(139): OC\Files\Config\MountProviderCollection->registerProvider(Object(OCA\Files_Sharing\MountProvider))\
#9 /srv/http/dev\/master/apps/files_sharing/appinfo/app.php(45): OCA\Files_Sharing\AppInfo\Application->registerMountProviders()\
#10 /srv/http/dev/master/lib/private/app.php(163): require_once('/srv/http/dev/m...')\
#11 /srv/http/dev/master/lib/private/app.php(144): OC_App::requireAppFile('files_sharing')\
#12 /srv/http/dev/master/lib/private/updater.php(460): OC_App::loadApp('files_sharing', false)\
#13 /srv/http/dev/master/lib/private/updater.php(329): OC\Updater->doAppUpgrade()\
#14 /srv/http/dev/master/lib/private/updater.php(215): OC\Updater->doUpgrade('9.1.0.0', '9.1.0.0')\
#15 /srv/http/dev/master/core/ajax/update.php(120): OC\Updater->upgrade()\
#16 {main}\",\"File\":\"/srv/http/dev/master/lib/private/share/share.php\",\"Line\":1539}","level":3,"time":"2016-03-22T21:46:21+00:00","method":"GET","url":"/master/core/ajax/update.php?requesttoken=ASdyHysbAjBjBFwNJQ4tGHlVOB8udQZCGj88DFQOUh4%3D%3A6W4Qgy3u%2BA8kRmU%2BKmtyg0jtXyX5mkbqZJ%2FXBIQk%2FwU%3D","user":"--"}

The instance might not be that clean, however an ownCloud instance existing since the old days might not be either ;)

Server configuration

Operating system: Antergos (Arch based)

Web server: Apache2

Database: MariaDB

PHP version: 5.6.17

ownCloud version: master

Updated from an older ownCloud or fresh install: updated

Where did you install ownCloud from: git

Are you using external storage, if yes which one: maybe

Are you using encryption: no

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

Logs

ownCloud log (data/owncloud.log)

see above

@DeepDiver1975 @rullzer anything we can / should do about this?

[rullzer]

Mmmm as far as I know I did not touch that part yet.
@blizzz how old exactly was the instance?

[blizzz]

Unknown. It's my master dev instance and I use to keep it going, but unregularly reset by unit test runs. I suspect an orphaned share triggering this thing. oc_share is now empty, unfortunately.

[billyburly]

I'm seeing the same behavior in Arch with the distro package. Also using LDAP & updated.

sudo -u http php occ upgrade
ownCloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Set log level to debug
Checking whether the database schema can be updated (this can take a long time depending on the database size)
Checked database schema update
Checking updates of apps
Checking whether the database schema for <dav> can be updated (this can take a long time depending on the database size)
Checked database schema update for apps
Updating database schema
Updated database
Disabled 3rd-party app: admin_migrate
Disabled 3rd-party app: files_odfviewer
Disabled 3rd-party app: user_migrate
Updating <dav> ...
Updated <dav> to 0.1.6
Exception: Sharing backend for file not found
Update failed
Maintenance mode is kept active
Reset log level

owncloud.log:

{"reqId":"bM9OHfL0\/9YWStqMxBpc","remoteAddr":"","app":"OCP\\Share","message":"Sharing backend for file not found","level":3,"time":"2016-04-07T14:29:33+00:00","method":"--","url":"--","user":"--"}
{"reqId":"bM9OHfL0\/9YWStqMxBpc","remoteAddr":"","app":"core","message":"Exception: {\"Exception\":\"Exception\",\"Message\":\"Sharing backend for file not found\",\"Code\":0,\"Trace\":\"#0 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/share\\\/share.php(1658): OC\\\\Share\\\\Share::getBackend('file')\\n#1 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/share\\\/share.php(335): OC\\\\Share\\\\Share::getItems('file', NULL, -1, '9b23d8ac-97a2-1...', NULL, -1, NULL, -1, false)\\n#2 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/public\\\/share.php(123): OC\\\\Share\\\\Share::getItemsSharedWithUser('file', '9b23d8ac-97a2-1...', -1, NULL, -1, false)\\n#3 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/apps\\\/files_sharing\\\/lib\\\/mountprovider.php(54): OCP\\\\Share::getItemsSharedWithUser('file', '9b23d8ac-97a2-1...')\\n#4 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/files\\\/filesystem.php(451): OCA\\\\Files_Sharing\\\\MountProvider->getMountsForUser(Object(OC\\\\User\\\\User), Object(OC\\\\Files\\\\Storage\\\\StorageFactory))\\n#5 [internal function]: OC\\\\Files\\\\Filesystem::OC\\\\Files\\\\{closure}(Object(OCA\\\\Files_Sharing\\\\MountProvider))\\n#6 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/hooks\\\/emittertrait.php(98): call_user_func_array(Object(Closure), Array)\\n#7 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/files\\\/config\\\/mountprovidercollection.php(87): OC\\\\Files\\\\Config\\\\MountProviderCollection->emit('\\\\\\\\OC\\\\\\\\Files\\\\\\\\Confi...', 'registerMountPr...', Array)\\n#8 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/apps\\\/files_sharing\\\/appinfo\\\/application.php(139): OC\\\\Files\\\\Config\\\\MountProviderCollection->registerProvider(Object(OCA\\\\Files_Sharing\\\\MountProvider))\\n#9 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/apps\\\/files_sharing\\\/appinfo\\\/app.php(45): OCA\\\\Files_Sharing\\\\AppInfo\\\\Application->registerMountProviders()\\n#10 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/app.php(163): require_once('\\\/usr\\\/share\\\/weba...')\\n#11 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/app.php(144): OC_App::requireAppFile('files_sharing')\\n#12 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/updater.php(460): OC_App::loadApp('files_sharing', false)\\n#13 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/updater.php(329): OC\\\\Updater->doAppUpgrade()\\n#14 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/updater.php(215): OC\\\\Updater->doUpgrade('9.0.1.3', '9.0.0.19')\\n#15 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/core\\\/command\\\/upgrade.php(246): OC\\\\Updater->upgrade()\\n#16 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/3rdparty\\\/symfony\\\/console\\\/Command\\\/Command.php(259): OC\\\\Core\\\\Command\\\\Upgrade->execute(Object(Symfony\\\\Component\\\\Console\\\\Input\\\\ArgvInput), Object(Symfony\\\\Component\\\\Console\\\\Output\\\\ConsoleOutput))\\n#17 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/core\\\/command\\\/base.php(158): Symfony\\\\Component\\\\Console\\\\Command\\\\Command->run(Object(Symfony\\\\Component\\\\Console\\\\Input\\\\ArgvInput), Object(Symfony\\\\Component\\\\Console\\\\Output\\\\ConsoleOutput))\\n#18 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/3rdparty\\\/symfony\\\/console\\\/Application.php(840): OC\\\\Core\\\\Command\\\\Base->run(Object(Symfony\\\\Component\\\\Console\\\\Input\\\\ArgvInput), Object(Symfony\\\\Component\\\\Console\\\\Output\\\\ConsoleOutput))\\n#19 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/3rdparty\\\/symfony\\\/console\\\/Application.php(192): Symfony\\\\Component\\\\Console\\\\Application->doRunCommand(Object(OC\\\\Core\\\\Command\\\\Upgrade), Object(Symfony\\\\Component\\\\Console\\\\Input\\\\ArgvInput), Object(Symfony\\\\Component\\\\Console\\\\Output\\\\ConsoleOutput))\\n#20 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/3rdparty\\\/symfony\\\/console\\\/Application.php(123): Symfony\\\\Component\\\\Console\\\\Application->doRun(Object(Symfony\\\\Component\\\\Console\\\\Input\\\\ArgvInput), Object(Symfony\\\\Component\\\\Console\\\\Output\\\\ConsoleOutput))\\n#21 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/console\\\/application.php(145): Symfony\\\\Component\\\\Console\\\\Application->run(Object(Symfony\\\\Component\\\\Console\\\\Input\\\\ArgvInput), Object(Symfony\\\\Component\\\\Console\\\\Output\\\\ConsoleOutput))\\n#22 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/console.php(88): OC\\\\Console\\\\Application->run()\\n#23 \\\/usr\\\/share\\\/webapps\\\/owncloud\\\/occ(11): require_once('\\\/usr\\\/share\\\/weba...')\\n#24 {main}\",\"File\":\"\\\/usr\\\/share\\\/webapps\\\/owncloud\\\/lib\\\/private\\\/share\\\/share.php\",\"Line\":1539}","level":3,"time":"2016-04-07T14:29:33+00:00","method":"--","url":"--","user":"--"}

[prislea]

I get the same error upgrading from 9.0.0.19 to 9.0.1.3(upgrade done with yum from CE stable repository).
Operating system: Centos 7, Web server: Apache/2.4.6, Database: MariaDB 5.5.47, PHP version: 5.6.20, LDAP external user-backend
update page says upgrad was unsuccessful. if I refresh I get the update page again and second time it says that is successful. until now seems that everything is working.

[olivierche]

I get the same error during occ upgrade

Server configuration
Operating system: CentOS Linux release 7.2.1511 (Core)
Web server: Apache httpd-2.4.6-40.el7.centos.x86_64
Database: mariadb-server-5.5.44
PHP version: php-5.4.16-36.el7_1.x86_64
ownCloud version: (see ownCloud admin page) : owncloud-files-9.0.0-1.1.noarch from isv_ownCloud_community repo (baseurl=http://download.opensuse.org/repositories/isv:/ownCloud:/community/CentOS_CentOS-7/ ) upgrade to 9.0.1 with yum update
External user-backend : openLDAP

I did the yum update then
sudo -u apache php /var/www/html/owncloud/occ upgrade that ends with :
Updating ...
Updated to 0.1.6
Exception: Sharing backend for file not found
Update failed
Maintenance mode is kept active

I ran sudo -u apache php /var/www/html/owncloud/occ upgrade a second time that ends without error.

[mgla]

The same error happens to me when updating from owncloud:amd64 9.0.0.-1-1 to 9.0.1-1.1 on Debian Jessie.

[blizzz]

changing milestone to 9.0.2, as to reports having issues here with 9.0. @rullzer @DeepDiver1975 do you have a clue what is going on here and/or what other information are necessary?

[rullzer]

I have no idea.
Could you list your enabled apps?

[caguiar]

I have the same error when upgrading owncloud in uBuntu 14.04, using the standard apt-get upgrade.

Here is the list of apps:
sudo -u www-data php occ app:list
Enabled:

• activity: 2.2.1
• comments: 0.2
• dav: 0.1.5
• federatedfilesharing: 0.1.0
• federation: 0.0.4
• files: 1.4.4
• files_external: 0.5.2
• files_pdfviewer: 0.8
• files_sharing: 0.9.1
• files_texteditor: 2.1
• files_trashbin: 0.8.0
• files_versions: 1.2.0
• files_videoplayer: 0.9.8
• firstrunwizard: 1.1
• gallery: 14.5.0
• notifications: 0.2.3
• provisioning_api: 0.4.1
• systemtags: 0.2
• templateeditor: 0.1
• updatenotification: 0.1.0
• user_ldap: 0.8.0

Disabled:

• encryption
• external
• user_external

[DeepDiver1975]

Is sharing disabled?

[caguiar]

#sudo -u www-data php occ config:app:get files_sharing enabled
yes

Is this what you enquired?

[inpos]

same issue after upgrade to 9.0.1
repeat occ upgrade finished successful, but I think something wrong

[simsasaile]

Same here Uprading 9.0.0 to 9.0.1 on debian jessie. Also have an "Some files have not passed the integrity check."-message. This are the files:

Results
=======
- files_sharing
    - EXTRA_FILE
        - lib/updater.php.rej

Raw output
==========
Array
(
    [files_sharing] => Array
        (
            [EXTRA_FILE] => Array
                (
                    [lib/updater.php.rej] => Array
                        (
                            [expected] => 
                            [current] => fb57fde4f5ef4971396dd27759fae0fe2269ff74d5dac8192ce2729a37b537d3c1b7013dd8f90ed025db26d90a9efbbbf24820103e62616966359175c5c19748
                        )

                )

        )

)

repeat occ upgrade helped also

[mayerthomas]

Same error occuring on Debian 8 updating OC from 9.0.0 to 9.0.2.

[PVince81]

The reason for this is still a mystery, need a way to reproduce this consistently.

Else need to try and infer from the code @icewind1991 @rullzer

[PVince81]

Would be good to have more information about the layout of the shares.
Also please all post your stack traces, they often contain the name of the failing user.
Then check "oc_share" for that user. Then we can try and correlate with the oc_filecache entry.
Maybe there's a deleted/invalid user/share involved.

[PVince81]

From what I see the "file" backend should be registered when loading the app: https://github.com/owncloud/core/blob/v9.0.2/apps/files_sharing/appinfo/app.php#L52

From what I see in @blizzz's stack trace, the code that triggers the FS setup happens before that line, here: https://github.com/owncloud/core/blob/v9.0.2/apps/files_sharing/appinfo/app.php#L45

Apparently this piece of code is already trying to get the shares even though the sharing subsystem isn't fully initialized yet. Also, this doesn't seem to happen on all system. The code in question is about propagating etags.

So I suspect that in your setups there were some changed files with pending propagation, and the update code would try and trigger that propagation here while on other systems it would not do anything.

A possible fix is to move the registerMountProvdiers and setupPropagation below the backend registration.

Will submit a PR for this.

[PVince81]

Looks like I was wrong about the cause. Wasn't able to reproduce the issue with that regards.

A quick debugging session shows me that the $mountProviderCollection has no listeners in my test cases. However in the stack trace above it seems there are listeners to the "registerMountProvider" event, and it's these listeners that triggers the bogus code.

Now to find out in what exact situation there are listeners there, during an update.

[PVince81]

Okay, more clues. it seems the hook that listen to it is triggered by setupFS($user).
So we're looking for a situation where something calls setupFS() before even loading the files_sharing app, and this during an update.

[PVince81]

Looking further, I see that @blizzz's stack trace contain a user name. This seems to imply that some part of the code believes that a user is currently logged in and has already set up the filesystem for that user. This shouldn't happen, during an update there is no current user, and if one is in the session, it is converted to "null" (aka "incognito mode"). So maybe the mode wasn't set early enough.

Another possibility is that before "files_sharing" got loaded, another app got updated which itself had a setupFS call within its update routines.

[PVince81]

Looking at https://github.com/owncloud/core/issues/23497#issuecomment-206936692 from @billyburly it looks like the only app that was loaded and updated before files_sharing is the "dav" app.

I see the "dav" app has some update code related to birthdays. Maybe there's a a special situation in which this would trigger avatar refetching, or even simpler "user fetching", which, when using LDAP, might implicitly also trigger the avatar logic, which itself relies on FS stuff.

If that's the case, I don't think we can easily prevent that.

So far the best fix would just to make sure that if the FS was setup before files_sharing is loaded, that the backends are also properly inited. And then I'll rely on you guys for helping test it :smile:

[PVince81]

Fix is here https://github.com/owncloud/core/pull/25159

Please help testing @blizzz @billyburly @prislea @olivierche @mgla @caguiar @mayerthomas @simsasaile

[PVince81]

OC 9.0 patch here: https://github.com/owncloud/core/pull/25187

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.