No longer importing Avatars Oauth

Description

I installed Rocket.Chat. I connect using an oauth. Avatars were imported from main site; great, working as it should. I upgraded Rocket.Chat and they stopped importing. I have recently upgraded Rocket.Chat again with the hope that the avatar was fixed. Nope, still will not import avatars. Also, can’t upload an avatar manually. I saw Accounts_AvatarStoreType on the net but can’t find that anywhere in the settings. I did see file storage and switched it to file system and now can’t upload files; permission denied even though the permissions are set to 777 which is the world. If avatars were imported before the upgrade and they stop working after the upgrade then it has to be something with the upgrade; that is just logical. Nothing else changed except Rocket.Chat.

Server Setup Information

  • Version of Rocket.Chat Server: 3.16.1
  • Operating System: CentOS 8
  • Deployment Method: Manual Install
  • Number of Running Instances: 1
  • DB Replicaset Oplog: Enabled
  • NodeJS Version: 12.18.4 - x64
  • MongoDB Version: 4.0.21
  • Proxy:
  • Firewalls involved: ip tables

Any additional Information


Exception while invoking method getUsernameSuggestion Error: Invalid user [error-invalid-user] at MethodInvocation.getUsernameSuggestion (app/lib/server/methods/getUsernameSuggestion.js:8:10) at MethodInvocation.methodsMap. (app/lib/server/lib/debug.js:76:34) at maybeAuditArgumentChecks (packages/ddp-server/livedata_server.js:1771:12) at packages/ddp-server/livedata_server.js:1689:15 at Meteor.EnvironmentVariable.EVp.withValue (packages/meteor.js:1234:12) at packages/ddp-server/livedata_server.js:1687:36 at new Promise () at Server.applyAsync (packages/ddp-server/livedata_server.js:1686:12) at Server.apply (packages/ddp-server/livedata_server.js:1625:26) at Server.call (packages/ddp-server/livedata_server.js:1607:17) at Object.post (app/api/server/v1/misc.js:263:26) at app/api/server/api.js:394:82 at Meteor.EnvironmentVariable.EVp.withValue (packages/meteor.js:1234:12) at Object._internalRouteActionHandler [as action] (app/api/server/api.js:394:39) at Route.share.Route.Route._callEndpoint (packages/nimble_restivus/lib/route.coffee:150:32) at packages/nimble_restivus/lib/route.coffee:59:33 at packages/simple_json-routes.js:98:9 => awaited here: at Promise.await (/opt/Rocket.Chat/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:60:12) at Server.apply (packages/ddp-server/livedata_server.js:1638:22) at Server.call (packages/ddp-server/livedata_server.js:1607:17) at Object.post (app/api/server/v1/misc.js:263:26) at app/api/server/api.js:394:82 at Meteor.EnvironmentVariable.EVp.withValue (packages/meteor.js:1234:12) at Object._internalRouteActionHandler [as action] (app/api/server/api.js:394:39) at Route.share.Route.Route._callEndpoint (packages/nimble_restivus/lib/route.coffee:150:32) at packages/nimble_restivus/lib/route.coffee:59:33 at packages/simple_json-routes.js:98:9 I20210709-19:13:22.372(1) Exception in setTimeout callback: TypeError: Cannot read property ‘etag’ of undefined at app/lib/server/functions/setUserAvatar.js:66:50 at Meteor.EnvironmentVariable.EVp.withValue (packages/meteor.js:1234:12) at packages/meteor.js:550:25 at runWithEnvironment (packages/meteor.js:1286:24)

You are going to make a mess of your data by switching to FiIeSystem without really understanding what you are doing.

GridFS stores the avatars in your Mongo DB. If you switch filesystems you can’t see the old Avatars stored there, or any other files…

FileSystem stores files on your server, but you need to make sure the file store is properly accessible by Rocket. Using 777 is dangerous. Change it IMMEDIATELY, and find the real reason you can’t store files there.

Please go back to the start and tell us the history of your server please.

Have a good read of this first.

It would have been nice to perhaps looked at the error code and maybe give some advice to why it is failing. Did you even read my post? I said it worked three installs back. Then I did an upgrade along with node.js and it stopped importing the avatars. Just did a second upgrade but same issue. Oh, someone else had the same issue but never got an answer. I have been a sys admin for 15 years now; yes, I know what 777 means. I was trying to illustrate that even with the world having full permissions Rocket.Chat could not store the file. By the way, when you go into settings, Rocket.Chat states that FileSystem is the preferred setting.

This is actually the second post about this problem. The first post after I did the upgrade went unanswered. Why even have this forum if there isn’t anyone that can help. I let the project sit; it actually isn’t in use because the avatars stopped working and you couldn’t even upload an avatar.

The problem is that all these “solutions” are over complicated; the KISS principle is very real. Rocket.Chat, Mattermost, Zulip, all way over complicated and thus half the time they just don’t work. Scale it down to just what is needed.

I guess I will dump Rocket.Chat after this latest update still has the avatars not working. If nothing on the server changed and I upgraded Rocket.Chat and the avatars stopped importing then it is Rocket.Chat. Doesn’t take a Rocket.Chat scientist to figure that out. At least I got to make a pun.

Hi.

I am trying to help here - we now have a community team and are making efforts to rebuild the community - you might like to check how much work we are doing here already.

If you have been an admin all this time then you know that rather than just jumping to conclusions we need to look to this logically. You know the full history of your server. We don’t. So we are blind.

Hence I said this:

You are jumping threads so we have unconnected information in different threads and so it is really hard to follow and get one consistent story to understand where things went wrong and why. Debugging is about being methodical and careful.

You are also changing your story which makes it hard to follow

That isn’t good when you are trying to debug - GridFS and FileStorage are different.

Note - the reason it can’t store them even with 777 is probably buried in your CentoOS logs - 777 doesn’t always = “allow anyone to store anything anywhere”. eg you might have something like AntiVirus running which can block it. Please have a search on the interwebs for say “file permission denied with 777”

Default setting is always for GridFS. Because GridFS does not require a working file system. I don’t believe anything tells you what the default should be?

The problem is what you need is not the same as what someone else needs.

How basic do you want it to be? Just manual user login only and no Oauth? No Avatars? Be careful what you wish for!!

We try to make it as easy to use as possible, but there are are competing needs and it is always hard to find a balance. We try our best.

Well we’re sorry to see you go, but that is open source. You are free to do whatever you want!!

If you want to stay around and for us to try and help you then let us know.

FWIW if you search github for your issue “Cannot read property ‘etag’” - which is always a good first step when debugging - you would probably see this:

Probably worth following up and reading around the connected issues and PRs. This may be related as well “Invalid user [error-invalid-user]”

Have a great day.

@john.crisp I just happened to be reading the Rocket.Chat Summary mail which brought me here and I wanted to let you know that you did an awesome job, despite the atmosphere of the thread being polluted from the get go.

1 Like

Glad someone does!!

You have made my day thanks!

Your feedback is really appreciated.

Have a great day!