Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain how to set/use `Accounts_AvatarStoreType` #978

Closed
mhkeller opened this issue Oct 2, 2015 · 32 comments

Comments

Projects
None yet
@mhkeller
Copy link

commented Oct 2, 2015

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

This comment has been minimized.

Copy link
Author

commented Oct 2, 2015

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

@mhkeller mhkeller changed the title Can't upload avatar Document `Accounts_AvatarStoreType` options and use cases Oct 2, 2015

@Sing-Li Sing-Li changed the title Document `Accounts_AvatarStoreType` options and use cases Explain how to set/use `Accounts_AvatarStoreType` Oct 3, 2015

@geekgonecrazy

This comment has been minimized.

Copy link
Member

commented Oct 3, 2015

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

This comment has been minimized.

Copy link
Author

commented Oct 5, 2015

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

@royalaid

This comment has been minimized.

Copy link

commented Oct 5, 2015

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

@amcdawes

This comment has been minimized.

Copy link

commented Oct 11, 2015

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

This comment has been minimized.

Copy link
Author

commented Oct 11, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 13, 2015

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

This comment has been minimized.

Copy link

commented Oct 15, 2015

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

This comment has been minimized.

Copy link

commented Oct 15, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 15, 2015

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

This comment has been minimized.

Copy link

commented Oct 16, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 17, 2015

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

This comment has been minimized.

Copy link

commented Oct 17, 2015

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

This comment has been minimized.

Copy link
Member

commented Oct 17, 2015

@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

This comment has been minimized.

Copy link

commented Oct 17, 2015

@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

This comment has been minimized.

@mhkeller

This comment has been minimized.

Copy link
Author

commented Oct 18, 2015

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

@Dbzman

This comment has been minimized.

Copy link

commented Oct 19, 2015

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

This comment has been minimized.

Copy link

commented Oct 19, 2015

Check to make sure your root_url is set.

@Dbzman

This comment has been minimized.

Copy link

commented Oct 20, 2015

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

@blaskovicz

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2015

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

This comment has been minimized.

Copy link

commented Oct 22, 2015

@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

This comment has been minimized.

Copy link

commented Oct 23, 2015

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

This comment has been minimized.

Copy link
Author

commented Oct 23, 2015

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

This comment has been minimized.

Copy link

commented Oct 31, 2015

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

This comment has been minimized.

Copy link

commented Nov 2, 2015

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

This comment has been minimized.

Copy link
Member

commented Nov 17, 2015

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

This comment has been minimized.

Copy link
Member

commented Nov 18, 2015

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

@k0nsl

This comment has been minimized.

Copy link
Contributor

commented Nov 18, 2015

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

@engelgabriel

This comment has been minimized.

Copy link
Member

commented Nov 18, 2015

Added

apt-get install -y graphicsmagick

and

USER rocketchat
RUN mkdir ~/uploads

to Dockerfile and made it the default path

@Sing-Li

This comment has been minimized.

Copy link
Member

commented Nov 18, 2015

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

This comment has been minimized.

Copy link
Member

commented Nov 29, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.