Missing Avatar after upgrade from 8.2.3 to 9.0.0 #22978

Closed
blizzz opened this Issue Mar 9, 2016 · 47 comments

Projects

None yet
@blizzz
Contributor
blizzz commented Mar 9, 2016

Steps to reproduce

  1. Have an avatar set in ownCloud. Mind: in the user home directory, there is only avatar.jpg, but no avatar.32.jpg
  2. Do the upgrade
  3. Login, or go to Personal or Users page

Expected behaviour

Avatar is visible as it was before

Actual behaviour

No Avatar in the header (but also no display name), placeholders in other places.

Copying the avatar.jpg file to avatar.32.jpg brings it back.

Server configuration

Operating system: Ubuntu 14.04

Web server: Apache 2

Database: MySQL

PHP version: 5.5.9

ownCloud version: 9.0.0

Updated from an older ownCloud or fresh install: Update from 8.2.3

Where did you install ownCloud from: Tarball

Signing status (ownCloud 9.0 and above): awesome

The content of config/config.php:

<?php
$CONFIG = array (
  'datadirectory' => '/var/lib/owncloud/ovin-data',
  'dbtype' => 'mysql',
  'version' => '9.0.0.19',
  'installedat' => '1326327271.69',
  'lastupdatedat' => '1338667774.87',
  'dbname' => 'foobar',
  'dbhost' => 'localhost',
  'dbtableprefix' => '',
  'dbuser' => 'barfoo',
  'dbpassword' => 'foo',
  'installed' => true,
  'instanceid' => '123456',
  'theme' => '',
  'maintenance' => false,
  'loglevel' => 1,
  'trusted_domains' => 
  array (
    0 => 'foo.de',
    1 => 'bar.de',
    2 => 'foobar.cu',
  ),
  'secret' => 'sadf',
  'share_folder' => '/Shared',
  'asset-pipeline.enabled' => false,
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/minion/ovin/apps',
      'url' => '/apps',
      'writable' => true,
    ),
    1 => 
    array (
      'path' => '/var/www/minion/apps-extra',
      'url' => '/../apps-extra',
      'writable' => true,
    ),
  ),
  'appstoreenabled' => true,
  'trashbin_retention_obligation' => 'auto',
);

Are you using encryption: no

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

Client configuration

Browser: FF 44

Operating system: Antergos Linux

Logs

ownCloud log (data/owncloud.log)

Nothing wrt Avatars

@blizzz blizzz added this to the 9.0.1-next-maintenance milestone Mar 9, 2016
@Psy-Virus

Hey,
I've a similar issue with my theme background image after the 8.2.2 -> 8.2.3 -> 9.0 upgrade.
Maybe the info helps.
If it's file ending is set to jpg, it won't load in the browser. The web server says a 302, also if I rename the file-name without the file type and change the related css.
If I change the file type to .png (with or without real conversion) and change the related css it is shown in the browser and the server gives a 200...

I tried to update the mimetypes with the related occ commands. But this changed nothing.

Btw. The owncloud logs do not say anything related to the background image.

That's strange

:-)

@rullzer rullzer assigned rullzer and unassigned rullzer Mar 9, 2016
@rullzer
Contributor
rullzer commented Mar 9, 2016

Does updating the avatar help? (So setting it again?).

@oxivanisher

I have the same issue and updating the avatar does not help.

@jmit79
jmit79 commented Mar 9, 2016

same here, I can't save a new avatar and the existing ones were broken. There's a NotPermittedException in the owncloud.log:

{"reqId":"dpEgL\/oljUh+SCCNTZRa","remoteAddr":"xxx.xxx.xxx.xxx","app":"core","message":"Exception: {\"Exception\":\"OCP\\\\Files\\\\NotPermittedException\",\"Message\":\"\",\"Code\":0,\"Trace\":\"
\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/avatar.php(121): OC\\\\Files\\\\Node\\\\Folder->newFile('avatar.png')
\\\/var\\\/www\\\/owncloud\\\/core\\\/controller\\\/avatarcontroller.php(315): OC\\\\Avatar->set(Object(OC_Image))
[internal function]: OC\\\\Core\\\\Controller\\\\AvatarController->postCroppedAvatar(Array)
\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/appframework\\\/http\\\/dispatcher.php(159): call_user_func_array(Array, Array)
\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/appframework\\\/http\\\/dispatcher.php(89): OC\\\\AppFramework\\\\Http\\\\Dispatcher->executeController(Object(OC\\\\Core\\\\Controller\\\\AvatarController), 'postCroppedAvat...')
\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/appframework\\\/app.php(110): OC\\\\AppFramework\\\\Http\\\\Dispatcher->dispatch(Object(OC\\\\Core\\\\Controller\\\\AvatarController), 'postCroppedAvat...')
\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/appframework\\\/routing\\\/routeactionhandler.php(45): OC\\\\AppFramework\\\\App::main('AvatarControlle...', 'postCroppedAvat...', Object(OC\\\\AppFramework\\\\DependencyInjection\\\\DIContainer), Array)
[internal function]: OC\\\\AppFramework\\\\routing\\\\RouteActionHandler->__invoke(Array)
\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/route\\\/router.php(273): call_user_func(Object(OC\\\\AppFramework\\\\routing\\\\RouteActionHandler), Array)
\\\/var\\\/www\\\/owncloud\\\/lib\\\/base.php(873): OC\\\\Route\\\\Router->match('\\\/avatar\\\/cropped')
\\\/var\\\/www\\\/owncloud\\\/index.php(39): OC::handleRequest()
{main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/files\\\/node\\\/folder.php\",\"Line\":171}","level":3,"time":"2016-03-09T09:29:24+00:00"}
@PVince81
Collaborator
PVince81 commented Mar 9, 2016

My avatar still worked after updating. I seem to have multiple in owncloud/data/vincent:

-rw-r--r--   1 wwwrun www  695 Mar  3 10:09 avatar.1.jpg
-rw-r--r--   1 wwwrun www 5.0K Mar  4 11:42 avatar.145.jpg
-rw-r--r--   1 wwwrun www 6.1K Mar  3 10:09 avatar.175.jpg
-rw-r--r--   1 wwwrun www 1.1K Mar  4 10:07 avatar.32.jpg
-rw-r--r--   1 wwwrun www 1.8K Mar  3 10:09 avatar.64.jpg
-rw-r--r--   1 wwwrun www  46K Oct 24  2013 avatar.jpg
@blizzz
Contributor
blizzz commented Mar 9, 2016

@PVince81 yes, because you have the avatar.$SIZE.jpg files. If you had only avatar.jpg, you'd run into the problem. I believe somewhere on the go, avatars were made to create and use files with size. Apparently, no miration of "old" avatars happened.

@rullzer
Contributor
rullzer commented Mar 9, 2016

@blizzz no there is no migration because they used to be created on the fly. They still are... but now we just store the result so the next requests takes the precreated one (if it is there).

@rullzer
Contributor
rullzer commented Mar 9, 2016

@PVince81 to double check... could your remove all of your avatar.*.jpg files? (so all but avatar.jpg) and see if they get recreated? (They do here).

@blizzz
Contributor
blizzz commented Mar 9, 2016

@rullzer on my dev system, if i remove the avatar it will be recreated. On the production system however, not.

@oxivanisher

I also tried deleting the avatar.jpg and it did not regenerate files after choosing a new file.

@PVince81
Collaborator
PVince81 commented Mar 9, 2016

@rullzer I deleted all of them, then logged in again in the web UI. No avatar was generated.

Then I reselected a jpg file directly from my OC and it generated those:

-rw-r--r--   1 wwwrun www 6.0K Mar  9 18:45 avatar.175.jpg
-rw-r--r--   1 wwwrun www 1.2K Mar  9 18:45 avatar.39.jpg
-rw-r--r--   1 wwwrun www  29K Mar  9 18:45 avatar.jpg
@rullzer rullzer was assigned by PVince81 Mar 9, 2016
@rullzer
Contributor
rullzer commented Mar 9, 2016

@blizzz @oxivanisher do you get a 404 or a different error code? (in the transfer console)

@rullzer
Contributor
rullzer commented Mar 9, 2016

@jmit79 that not permitted exception looks ๐ŸŸ-y... Altough I have no clue where it comes from...

@blizzz
Contributor
blizzz commented Mar 9, 2016

@blizzz @oxivanisher do you get a 404 or a different error code? (in the transfer console)

nope, always 200

@blizzz
Contributor
blizzz commented Mar 10, 2016

@rullzer with removed catches I get this three times on the personal page (3 sizes are requested)

{"reqId":"2KMqS/AzeGgF4NWhulqu","remoteAddr":"109.45.2.130","app":"index","message":"Exception: {\"Exception\":\"OCP\Files\NotPermittedException\",\"Message\":\"\",\"Code\":0,\"Trace\":\"#0 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/avatar.php(163): OC\Files\Node\File->getContent()\
#1 \/var\/www\/minion\/ovin-9.0.0\/core\/controller\/avatarcontroller.php(117): OC\Avatar->getFile(1)\
#2 [internal function]: OC\Core\Controller\AvatarController->getAvatar('arthur', 1)\
#3 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/appframework\/http\/dispatcher.php(159): call_user_func_array(Array, Array)\
#4 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/appframework\/http\/dispatcher.php(89): OC\AppFramework\Http\Dispatcher->executeController(Object(OC\Core\Controller\AvatarController), 'getAvatar')\
#5 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/appframework\/app.php(110): OC\AppFramework\Http\Dispatcher->dispatch(Object(OC\Core\Controller\AvatarController), 'getAvatar')\
#6 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/appframework\/routing\/routeactionhandler.php(45): OC\AppFramework\App::main('AvatarControlle...', 'getAvatar', Object(OC\AppFramework\DependencyInjection\DIContainer), Array)\
#7 [internal function]: OC\AppFramework\routing\RouteActionHandler->__invoke(Array)\
#8 \/var\/www\/minion\/ovin-9.0.0\/lib\/private\/route\/router.php(273): call_user_func(Object(OC\AppFramework\routing\RouteActionHandler), Array)\
#9 \/var\/www\/minion\/ovin-9.0.0\/lib\/base.php(873): OC\Route\Router->match('\/avatar\/arthur\/...')\
#10 \/var\/www\/minion\/ovin-9.0.0\/index.php(39): OC::handleRequest()\
#11 {main}\",\"File\":\"\/var\/www\/minion\/ovin-9.0.0\/lib\/private\/files\/node\/file.php\",\"Line\":42}","level":3,"time":"2016-03-10T09:20:27+00:00"}
@rullzer
Contributor
rullzer commented Mar 10, 2016

Ok so it boils down to https://github.com/owncloud/core/blob/master/lib/private/files/node/file.php#L57 Which to me looks like invalid permissions in the oc_filecache table. @blizzz confirmed that they are 0.

Now this only happens now since I switched over the avatar code to the Node API.

@icewind1991 any idea how we can fix the broken entries?

@blizzz
Contributor
blizzz commented Mar 10, 2016

setting permissions to 27 did not make it work.

Users with issues had two entries about the avatar in the filecache table. One tied to their own storage, one to the data-dir-storage.

However, fixing permissions and removing the avatar entry belonging to the data-dir-storage did not make it work either.

@icewind1991
Member

setting permissions to 27 did not make it work.

It should be 31

@blizzz
Contributor
blizzz commented Mar 11, 2016

@icewind1991 setting them to 31 does not have any impact either.

@icewind1991
Member

#23154 should keep avatars visible even when we cant save the resized one

@rullzer
Contributor
rullzer commented Mar 11, 2016

It should be 31

No it is a file... so there are no create permissions right?

@blizzz
Contributor
blizzz commented Mar 11, 2016

The entry with empty name and path (parent -1) of my storage has permissions of 0. Is it how it should be? Maybe that should be 31 as well?

@icewind1991
Member

Yes, that's the one that's actually important, that folder needs create permissions

@blizzz
Contributor
blizzz commented Mar 11, 2016

My data dir storage has almost 17k entries in the filecache. And most of them belong to users. Is this correct? if I exclude all the user related paths, I am down to 29 entries (inlcuding user folders).

@blizzz
Contributor
blizzz commented Mar 11, 2016

The entry with empty name and path (parent -1) of my storage has permissions of 0. Is it how it should be? Maybe that should be 31 as well?

Changing this fixes it for me.

@rullzer
Contributor
rullzer commented Mar 11, 2016

@icewind1991 so actually we would need a repair step to set the correct permissions on the parent?

@rullzer rullzer assigned icewind1991 and unassigned rullzer Mar 14, 2016
@PVince81
Collaborator

Not sure if that's really a "high" issue if it only occurs when permissions were wrong.

The question is how could the permissions be wrong in the first place ?

@rullzer
Contributor
rullzer commented Mar 16, 2016

@PVince81 yeah that is the question indeed. I know it happened to a few users at least (@dragotin was also affected). So it might be that it is mostly older installations.

@icewind1991
Member

imo we can lower the priority on this or maybe even close this in favor of a "check why the home folder permissions can get messed up" issue

@PVince81
Collaborator

Agreed. How about adding an additional setup check to find out whether permissions are wrong ? Or improve the existing one ?

@oxivanisher

Or even a administrative task to "fix permissions" (executable from the admin gui).

@PVince81
Collaborator

Reducing severity now that the regression was fixed.
Also moving to 9.0.2 to look for a better check for messed up permissions, possibly in the setup checks.

CC @cmonteroluque

@icewind1991 icewind1991 added sev2-high and removed sev3-medium labels Mar 24, 2016
@Wikinaut
Contributor

I have the same problem after upgrading to oc 9.0.0.

In my three-user owncloud, two avatars are missing (and cannot be set, I tried jpg and png), one is present and could be updated (changed).

@cmonteroluque
Contributor

@PVince81 ok, I had my doubts about the severity drop, but 9.0.2 makes sense. @icewind1991 how come bringing it back to 9.0.1?

@Wikinaut
Contributor
Wikinaut commented Apr 9, 2016

Not fixed in OC 9.0.1

@DeepDiver1975
Member

Not fixed in OC 9.0.1

indeed - #23892

@Moimemeici Moimemeici referenced this issue in Wonderfall/dockerfiles May 5, 2016
Closed

Owncloud / Contact App #4

@oxivanisher

Can at least someone post a way to fix this? Since it is still not fixed in 9.0.2.
(changing the permission to 23 or 31 did not help)

@gig13 gig13 added the blue-ticket label May 18, 2016
@gig13
gig13 commented May 23, 2016

@bboule @PVince81 Any updates?

@atnexxt
atnexxt commented May 26, 2016

I did a rescan of my user files php occ files:scan [user-id] on the console and got my avatar image back visible.

@oxivanisher

@atnexxt thanks! that worked ๐Ÿ‘

@gig13
gig13 commented May 26, 2016

@bboule @PVince81 Could this be added to OC8.2.x maintenance release?

@Wikinaut
Contributor

@atnexxt GREAT!

sudo -u www-data php occ files:scan --all

solved the problem.

@axel-dd
axel-dd commented May 26, 2016 edited

Thx works for me too.

For users on all-inkl shared webspace do the following...

  1. use all-inkl WebFTP to chown owncloud folder permissions to ftp user (e.g. w123456) recursively
  2. temporary move the .htaccess file out of the owncloud root folder (e.g move it to resources folder)
  3. create a run.phpx file in the owncloud root folder with the following content
    <?php echo exec('php occ files:scan --all'); ?>
  4. now run the file https://myowncloud.url/run.phpx and wait until it is finished
  5. now you can remove the run.phpx file
  6. move the .htaccess file back to the owncloud root folder
  7. use all-inkl WebFTP to chown owncloud folder permissions back to php user recursively

Now your avatar images should be back.

@rullzer
Contributor
rullzer commented May 27, 2016

A awesome that there is a fix.
Still I think it would be good to have a repair step to fix the permissions on the root and users roots. @icewind1991 do you agree? (I can write such a repair step)

@icewind1991
Member

A repair step would make the most sense

@rullzer
Contributor
rullzer commented May 27, 2016

Ok I'll fix that somewhere next week

@PVince81 PVince81 assigned rullzer and unassigned icewind1991 May 30, 2016
@rullzer rullzer added a commit that referenced this issue May 30, 2016
@rullzer rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
b94f55e
@rullzer
Contributor
rullzer commented May 30, 2016

PR in #24898

@rullzer rullzer added a commit that referenced this issue May 30, 2016
@rullzer rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
d6da6a7
@rullzer rullzer added a commit that referenced this issue May 30, 2016
@rullzer rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
dbdaf56
@rullzer rullzer added a commit that referenced this issue May 30, 2016
@rullzer rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
88cb325
@rullzer rullzer added a commit that referenced this issue May 30, 2016
@rullzer rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
9ace419
@rullzer rullzer added a commit that referenced this issue May 31, 2016
@rullzer rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
556d6ad
@rullzer rullzer added a commit that referenced this issue Jun 1, 2016
@rullzer rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
d3005c4
@rullzer rullzer added a commit that referenced this issue Jun 3, 2016
@rullzer rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
c06bebe
@rullzer rullzer added a commit that referenced this issue Jun 6, 2016
@rullzer @rullzer rullzer + rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
2bd0aff
@rullzer rullzer added a commit that referenced this issue Jun 8, 2016
@rullzer @rullzer rullzer + rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
8b96e91
@rullzer rullzer added a commit that referenced this issue Jun 10, 2016
@rullzer @rullzer rullzer + rullzer Repair job to fix permissions for avatars
Fixes #22978

On some older installations the permissions for the userRoot and the
avatars are not correct. This breaks since we now use the Node API in
the avatar code.

This repair job makes sure that the permissions are set correctly.

* Unit tests added
1b66db7
@PVince81 PVince81 closed this in #24898 Jun 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment