Explain how to set/use Accounts_AvatarStoreType

[mhkeller]

When running through docker-compose, I can't upload an image as an avatar. I'm not sure how to ssh into the docker vm to see if that directory exists but happy to help debug. I do get a notification that the upload and image change was successful, however.

[mhkeller]

Changing the type to FileSystem works now. Could this be documented on why this works / maybe a dropdown menu to choose between options:

[geekgonecrazy]

When running through docker-compose, I can't upload an image as an avatar. I'm not sure how to ssh into the docker vm to see if that directory exists but happy to help debug. I do get a notification that the upload and image change was successful, however.

So using the docker-compose setup out of the box i'd for sure not recommend using fileSystem storage at all.

If it actually works it'll be in the container. When you goto upgrade the rocket.chat container for a new version your files will be gone.

You need to add a volume in your docker-compose file and map a folder inside the container to outside.

Something like:

volumes:
   - ./files:/var/www/uploads

As far as the types of storage used I agree these do need documented or a dropdown.

[mhkeller]

Got it. Is using GridFS what you would recommend? Does that route require any additional configuration?

[royalaid]

I just want to echo that out of the box the GridFS setup for avatars and docker does not work for me either.

[amcdawes]

Running out-of-the box with docker-compose I don't see avatar changes with GridFS (default) or with FileSystem. Is there anything else you changed mhkeller?

[mhkeller]

after updating the latest neither are working for me either.

On Sun, Oct 11, 2015 at 5:51 PM, Andrew M. C. Dawes <
notifications@github.com> wrote:

Running out-of-the box with docker-compose I don't see avatar changes with
GridFS (default) or with FileSystem. Is there anything else you changed
mhkeller?

—
Reply to this email directly or view it on GitHub
#978 (comment)
.

@mhkeller
mhkeller.com

[MuhClaren]

after updating the latest neither are working for me either.

Confirmed.

Upload appears to have worked, Rocket.Chat renders the balloon notification stating the avatar change was successful, and I can see the changed avatar. However, the change doesn't survive a page refresh, logout, nor a reboot of the server.

Before (I can see the avatar):

<div class="avatar-image" style="background-image:url(/avatar/admin.jpg?_dc=478);">

After (I cannot see the avatar image, only the initials):

<div class="avatar-image" style="background-image:url(/avatar/admin.jpg?_dc=0);">

Running default docker-compose out of the box, auto-starting on boot with init script.

EDIT: I tried adding the volume definition to docker-compose.yml. No joy.

rocketchat:
  image: rocketchat/rocket.chat
  environment:
    - MONGO_URL=mongodb://mongodb/rocketchat
    - ROOT_URL=https://chat.mydomain.com
  links:
    - mongodb
  ports:
    - 80:80
  volumes:
    - ./files:/var/www/rocket.chat/uploads/

[Dbzman]

We also noticed the exact same problem with avatars today. (using docker, too)
Avatar settings in RocketChat are configured like this:
Accounts_AvatarStorePath: /var/www/rocket.chat/uploads/avatar/
Accounts_AvatarStoreType: GridFS (we tried FileSystem also)

Then I mounted "/var/www/rocket.chat/uploads/avatar/" to the host system (also because this default path did not exist in the docker container) and checked the if the avatars are uploaded there (container and host). There were not.

[royalaid]

I had to change the path that RocketChat uses, current I am mounting $PWD/avatarstore:/avatarstore and using /avatarstore inside rocketchat for the avatar storage path.

[MuhClaren]

I saw a commit related to avatars yesterday (or was it two days ago), and launched a new instance of the docker Rocket Chat image, which seems to have fixed the issue for me.

Avatars are sticking now, and surviving reboots, logouts, etc.

Correction: I was mistaken. The problem persists under v0.7.1891. If I enable resizing, any operation with avatars causes a hard fault / crashes the server. Avatars are not surviving through to a new session.

[Dbzman]

That didn't fix it for me. Now when I upload an avatar the App crashes with this.

[methods] setAvatarFromService ->  userId: P4FdQnrRgn7bt8FRm contentType: image/jpeg service: upload

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: spawn ENOENT
    at errnoException (child_process.js:1011:11)
    at Process.ChildProcess._handle.onexit (child_process.js:802:34)

EDIT:
After setting the Storage Type to "FileSystem" also the error does not occur again but avatars are not persisted. :/

EDIT 2:
I changed it back to GridFS and it seems to work again. Only the Desktop App does not pick up the new avatar.

EDIT 3:
Some users still have issues adding avatars.

[MuhClaren]

UPDATE / WORK-AROUND:

In the chat admin panel, click on Accounts. Find "Accounts_AvatarStorePath" and remove any path in the field. Save it as a blank field. Currently, rocketchat looks for any string in this field, and sets it as the avatar store path. Since we now know that the pre-populated path in that field is buggy due to permissions, by removing all content and saving it as empty field causes rocketchat to use by default ~/uploads path in the container, which does indeed have proper permissions.

[Dbzman]

@MuhClaren
Thanks for investigating! :)
I played around with that a bit (dev version, no docker) and see similar issues.

• AvatarResize causes the server to crash with boths store types
• with GridFS the avatars are at least persisted but not overwritable (see Cannot overwrite avatar #1150)
• with FileSystem and a folder with correct permissions I can see the files are placed there but after a site refresh the avatar is not shown again (but laying around on the filesystem)

[MuhClaren]

@Dbzman

I too had every single one of those problems, using the docker automated build image, which is basically bleeding edge code that is built into a docker image every time a repository commit is made.

After performing the steps I've illustrated above, every one of those problems are gone, including the crashing when avatar resize is on. The images display as they should now, and persist when changed by the user. I'm finishing up my guide and will have it published to the wiki in a few hours. I encourage anyone struggling with these issues to check it out.

Kind regards.

[Dbzman]

@MuhClaren

That's interesting. I even tried to empty the "Accounts_AvatarStorePath" you mentioned and had the 3 issues I described in the post above.

Some minutes ago I just tried it again with this configuration:

AvatarResize: true
AvatarStorePath:
AvatarStoreType: FileSystem

And now it seems to work correctly, so I can

• upload avatars without crashing the server
• see the current avatar on the filesystem
• see the current avatar even after a page refresh

I don't know why this works now (Maybe there were some broken caches?) but your workaround seems to be working perfectly! I'll try this on our docker environment on Monday to see if this can be fixed there as well. (probably using your guide) :)

Many thanks and best regards

[MuhClaren]

@Dbzman Glad it's working for you!

Guide: https://github.com/RocketChat/Rocket.Chat/wiki/Docker-Ubuntu-14.04-%2864-bit%29-VPS-with-Nginx-SSL-and-Hubot

[mhkeller]

Has anyone been using the heroku deploy method and running into issues? I just spun one up and can't set custom avatars.

[Dbzman]

I just tried it again on our docker environment. (Using this docker image: "https://hub.docker.com/r/rocketchat/rocket.chat/")
The problem is that $HOME is pointing to the none existing folder "/home/rocketchat" and I cannot find any folder which is accessible by the rocketchat user. (besides "/tmp/ufs" which also leads to crashes when I upload an avatar using this folder) If I mount a folder to the host system it is still owned by root:root. I think for now I'll fall back to GridFS and live with the issue that I cannot overwrite avatars.

EDIT: After playing around with FileSystem and GridFS I see crashes everytime. :(

EDIT 2: After re-creating the container the Avatars with GridFS work as before...

EDIT 3: Ok, GridFS is broken again. Avatars are not persisted anymore. At least not shown. When I open the image directly I can see my avatar but in the application it is still wrong. Clearing the caches also does not help. This only occurs on Safari. The app and Chrome work perfectly.

[royalaid]

Check to make sure your root_url is set.

[Dbzman]

@mhkeller
Do you see anything in the logs when you set an avatar?

[blaskovicz]

I was able to get the avatar upload working with the following settings (but I'd like to say that the errors / server crashing / lack of logging feedback leave a lot to be desired in terms of debugging this issue):

resize: false
size: 20000
path: /home/username/some/dir/that/exists
type: FileSystem

[Dbzman]

@blaskovicz
I tried it with the docker container again using your settings. Only Safari currently reverts back to the initials. Probably the fix from @MuhClaren works better than I thought because I always used Safari which seems to have caching issues here.

I also have to find a writable folder which can be used. (I don't like to use "/tmp") I guess in the Dockerfile such a folder should be created.

[Dbzman]

Again I tried it with the docker container.
FileSystem seems to reliably store avatars and delete them. The only issue I have is:
After changing the avatar I have to open the image directly to get a non-cached version. (Even Force-Reload multiple times does not help; affects Safari and Chrome so far)
And as soon as I mount the folder to my host system the folder is owned by root again and I cannot write to it anymore. :(

[mhkeller]

I'm using heroku deploy now with FileSystem and /var/www/rocket.chat/uploads/avatar/ as the path. Uploads work, but similar to the above, they don't persist for the user on refresh.

[Porco-Rosso]

using the below configuration does indeed allow me to upload the image, and I can find it stored under ~/uploads
however, refreshing breaks this, and the image goes back to displaying the username initials despite the file still being under ~/uploads and having the correct permissions.

resize: false
size: 500
path: 
type: FileSystem

I can notice the html works when set as:
/avatar/username.jpg?_dc=512
But it goes back to
/avatar/username.jpg?_dc=0
after refresh. What does dc=x do?

PS: on Ubuntu 14.04

[Porco-Rosso]

Somehow the issue has resolved itself.
Under chrome I had to check Disable cache (while DevTools is open) from the developer tools options and refresh the page to get it to work.

[engelgabriel]

The ?_dc is the main problem here. We don't store the file version anywhere, we just increment the number when people change avatar to get the new file, and we were expecting the cache to be small enough that the ?_dc=0 would be re-fetched next time the person login.

We need to fine tune this setting, so the cache only persist for that session, so by the time the ?_dc=x is reset, so is the cache.

[engelgabriel]

We fixed the cache problem, now it should persist for the user on refresh :) can anyone test it?

[k0nsl]

@engelgabriel: I can confirm it to be fixed on my own instance. 👍

[engelgabriel]

Added

apt-get install -y graphicsmagick

and

USER rocketchat
RUN mkdir ~/uploads

to Dockerfile and made it the default path

[Sing-Li]

Please test the latest docker image rocketchat/rocket.chat

It now should save avatar files across restart, even if you changed to Accounts_AvatarStoreType to FileSystem for storage.

Let us know if it works for you. Thanks.

[MuhClaren]

@Sing-Li Tested in a freshly rolled docker instance on Ubuntu 14.04 - x64, using all default settings, including GridFS and no path defined in the admin UI. After I purged the browser cache, it worked as intended. Avatars stuck and survived session changes, reboots, etc. 👍

Nice work!