No longer importing Avatars Oauth

Community Support
1

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)

2

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.

1 Like
3

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.

4

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.

5

@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
6

Glad someone does!!

You have made my day thanks!

Your feedback is really appreciated.

Have a great day!

7

The funny thing is that not one useful piece of information was offered that might outline what the problem might be. Evidently those viewing the error log file here was just as clueless as I was on what the dang error log was showing. Usually on sites you have people that look at the log file and say, “Oh, right there is telling you what is wrong,” The Rocket.Chat error log is mostly gobble gook unless you are the programmers. Seriously, I fully expected a knowledgeable person to look at the error log and give me an indication of what is failing. Perhaps rewrite the error output to be more understandable to someone that isn’t on the programming team. PHP is a great example, when you get an error output, you know exactly why the code is failing to compile.

So here we are after all this time and you haven’t helped me, and you haven’t helped any of the others that have posted with the same issues. I recently told someone on another forum that if after installing Rocket.Chat and it doesn’t work, don’t expect to get help from Rocket.Chat, either here or on the chat site.

I may wipe mongo and rocket.chat and try installing fresh and see what happens. It was working on the same sever with the same everything but then stopped with an upgrade. Someone else posted the same issue as me and the answer they got was to wait for the next release. OK, I waited till the next release and it is still broken. Maybe another look at Zulip.

8

That is because you had an issue and then tried a few different actions that compounded the original situation rather than trying to sit down and methodically work out what had gone wrong right at the outset. Upgrading again and randomly changing things rarely fixes issues IME.

So we now have a slightly tangled web and need to try and go back and work out what is wrong.

We have asked more than once for a history of the server which you have not provided.

No mention of if you run in a sub directory, web proxies, http/s or anything else that might be related. No other visible evidence of the error.

That really depends on whether the log extract tells us what is wrong - and your extract probably doesn’t. As above you probably also want to include web server logs, and possibly browser error console logs too.

(BTW you really ought to upgrade to at least 3.16.4 now - check the releases page))

I’m not sure it does? Can you show me that? There is no ‘preferred’ setting in Rocket Admin as far as I am aware.

GridFS is the default. But we don’t recommend it for larger installations and it can have performance issues at scale.

Changing it with out preparation is likely to cause issues. There are plenty of threads on that and how to migrate your data correctly.

That’s because we don’t have enough information to understand the issue.

Well that is disappointing as it isn’t true right now. It might have been true going back a several months, but it isn’t now if you actually take a look.

The new Community Team had been trying to answer every query. If we can’t answer it we can speak to developers, but to do that we need all the right information to ask a well prepared question.

As I have said before. please do this methodically, and document your steps. You made no mention of an accurate history with the versions being used and where things broke. We can’t just guess at that sort of thing.

I believe there may have been some issues that have been resolved recently but without knowing more detail it is impossible to say.

Where?

Note - if someone spots an issue then we always ask for it to be tested on latest code - issues are being fixed all the time and 2 months is a long time with Rocket.Chat. I can’t change that.

Please use your years of experience here and document this properly and then we can try and look.

But right now we don’t have enough information to help you.

9

The responses John are unreal. OK, Let’s start with the error report and go from there. John, go through that report and explain line by line what it is telling us. I don’t know; to me it tells me nothing. However, it must be telling us something or you wouldn’t have coded it to generate that report. If this is just useless information, then remove that part of the code as it is just taking up space. If not, then let’s walk through line by line as it may provide some clues.

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)

10

Yes, you are correct John; you actually recommend that we use a third party for file storage that we have no control over. Rocket.chat recommended Amazon or Google, two of the worst corporations on the planet. If I am self hosting I think I can just use my own server.

What we recommend as the best option for the file upload system are Amazon S3 and Google Cloud Storage .

11

We understand you are reinstalling anyway, so largely this may be irrelevant.

The key take out here is we have asked a few times for more information because if we approach a developer and ask for their assistance it is the first thing they are going to ask me. We don’t ask this just to annoy you.

If there is genuinely an issue you’d need to follow this:

https://docs.rocket.chat/contributors/how-can-i-help/reporting-issues

And then fill this out:

Having assisted with triage for quite some time we find it avoids the classic XY Problem.

As you have said yourself, you don’t understand the log - that’s why you are asking here. It isn’t very well formatted but looks like two errors - possibly connected, possibly not:

Error: Invalid user [error-invalid-user]

TypeError: Cannot read property ‘etag’ of undefined

A lot of the rest is just additional debugging info, but isn’t necessarily relevant at this point in time. We know enough to know that we can’t work out what your problem is just from that and need more information.

Hence the additional questions, particularly your web server logs and any browser console logs and information on your proxy etc.

So please accept that on this case it isn’t just as simple as ‘look at the log and give you a fix’, especially bearing in mind all your storage issues previously mentioned.

What we recommend as the best option for the file upload system are Amazon S3 and Google Cloud Storage .

No, it doesn’t actually say that. It says:

It says ‘storage type’.

As far as cloud storage goes you can use any compatible system - it does not have to be those specifically.

I use this on one of my own servers. No Amazon included…

https://hub.docker.com/r/minio/minio/

12

Agree with you. RC logs a bit confusing and not so helpful in some situations. But they improve that aspect from time to time. Here is an example - [FIX] Remove stack traces from Meteor errors when debug setting is disabled by matheusbsilva137 · Pull Request #22699 · RocketChat/Rocket.Chat · GitHub

That’s just not true.
You didn’t give us details John asked you, but you blame, that hi didn’t helped you, what fault it is?

Not true again.
I’ve got a lot of help form here and GitHub. And helped some people in their issues, where I could do that.

Worth to try. You can try do backup messages and users and then restore it.

My experience about avatar and files in general in Rocket.Chat pretty good. We use minIO as Amazon S3 file provider and all works almost perfect, despite sometime on LDAP sync process we get etag undefined and someone gets broken avatar until next sync.
So, my advice is to try minIO - it’s free and reliable.