Your Rocket.Chat version:0.42.0
When I select the file to upload the percentage loading does not advance. What can be happening?
+1. I used the 0.45.0 docker container and noticed the same behavior.
In addition I noticed the following message while starting the rocketchat container:
ufs: permissions are not defined for store "rocketchat_uploads"
I just tried on 0.45.0 with a pdf and works fine form chrome under linux
in admin/Upload/Accepted Media Types I have:
video/webm,audio/wav,image/_,audio/_,video/*,application/zip,application/x-rar-compressed,application/pdf,text/plain,application/msword,application/vnd.openxmlformats-officedocument.wordprocessingml.document
+1
It looks like it is a file permissions issue
I changed the uploads directory permissions to 777 and the uploads happened just fine
Couldn't we mention it as part of the getting started documentation, when
running a Docker container? 777 is kind of a dangerous permission for a
folder. We could have it defined a bit stricter, I guess.
On Fri, Nov 18, 2016 at 12:45 PM, Lance Haig [email protected]
wrote:
It looks like it is a file permissions issue
I changed the uploads directory permissions to 777 and the uploads
happened just fine—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/RocketChat/Rocket.Chat/issues/4923#issuecomment-261502528,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APv-ut6n56eHr3JlR6uE1Sfuasyn6tBYks5q_YG-gaJpZM4KvUdq
.
4.5 with Storage Type: FileSystem here. Workaround changed the Protect uploaded files from True to False.
Same problem here. rocket.chat v0.46 @ docker
@lhaig which path is the uploads directory ? thx
I have change mongodb that create new db and it is work fine
Same problem here as well. rocket.chat v0.48.2 @ centOS
Storage Type: FileSystem
Same problems in the browser console I get:
Error interpretation XML: no root item finded
address: https://domain/ufs/rocketchat_uploads/Ebbja9Byj8amLfPsC?token=aB580BAAd9&progress=0.042649562415073124
row number 1, column 1:
In the log of rocketchat i get:
rocketchat_lib.js:1011 [34mMeteor âž” method ufsCreate -> userId: zNhSzWt9nYWdA8mvD , arguments: { '0': { name: 'photo_2016-12-12_12-47-13.jpg', size: 127514, type: 'image/jpeg', rid: 'W9pqtxsoD5R827v5n', store: 'rocketchat_uploads' } }
[34mI20170104-12:06:41.819(0) rocketchat_lib.js:1011 [34mMeteor âž” method ufsDelete -> userId: zNhSzWt9nYWdA8mvD , arguments: { '0': 'cDCJ9QPCXgodeHp7E', '1': 'rocketchat_uploads', '2': '4B4A4A6B28' }
I changed the settings to use the filesystem and i get this:
[34mI20170104-12:16:40.287(0) rocketchat_lib.js:1011 [34mMeteor âž” method ufsCreate -> userId: zNhSzWt9nYWdA8mvD , arguments: { '0': { name: 'photo_2016-12-12_12-47-13.jpg', size: 127514, type: 'image/jpeg', rid: 'W9pqtxsoD5R827v5n', store: 'fileSystem' } }
[34mI20170104-12:16:41.031(0) rocketchat_lib.js:1011 [34mMeteor âž” method ufsDelete -> userId: zNhSzWt9nYWdA8mvD , arguments: { '0': 'uShe7YRyG2Yfjaiy5', '1': 'fileSystem', '2': '98481a99Da' }
But the error in console is the same and in the folder that I configured I get no files.
We got it to work by following a post in the Ubuntu Snap Rocket.Chat channel.
"Goto Administration->File Upload and switch storage type from GridFS to FileSystem. Then down under the File System section put this: /var/snap/rocketchat-server/common/uploads
into that field."
I also ended up restarting the server after making the change, I'm not sure if that had anything to do with it working, but it wasn't working even after the change until I restarted it.
I got it working after a complete reboot of the server with the above mentioned settings. The only thing that we've changed is Protect uploaded files
to false
Yes a reboot of the rocketchat service with file upload on filesystem fixed everything :-)
I'm having exactly this issue on Debian 8.7, not snap, manual install. I posted it in #4897 before I realised that's closed and probably won't be responded to. Package versions:
# nodejs --version
v0.10.29
# npm --version
2.15.9
Rocket.Chat version is 0.52.0, avatar uploads using GridFS work just fine, file uploads don't work at all, stop at 0% uploading. Tried FileSystem, GridFS, turned off Protected mode as suggested in some related threads, all to no avail. File upload into a chat and microphone recordings simply do not work. I also don't get any messages in the server syslog or the Rocket.Chat log in the UI (can't find where Rocket.Chat logs on disk, the nodejs log is empty).
Any suggestions / ideas? :-)
@gregharvey I have the same problem. File Upload is working if I run Rocket.chat as root, but this is really not a good idea. This tells me it's likely a permission problem.
I run the latest version of Rocket.chat and nodejs version 4.7.3 (same as snap) on Debian 8.
Then in my logs I found this:
ufs: cannot write chunk of file "XKzERG69TKpAXQuRe" (EACCES: permission denied, open '/tmp/ufs/XKzERG69TKpAXQuRe')
ufs: cannot delete temp file "/tmp/ufs/XKzERG69TKpAXQuRe" (EACCES: permission denied, unlink '/tmp/ufs/XKzERG69TKpAXQuRe')
And the solution is pretty easy: chown rocketchat:rocketchat /tmp/ufs
(rocketchat is the user that I use for Rocket.Chat)
Now I can upload files without any problems.
THS-on
@THS-on Thanks for the update. Unfortunately I'm not seeing anything in the logs, and even if I (temporarily) chmod 777 the upload directory it still doesn't work, so in my case it doesn't seem to be permissions...
@THS-on Oh wow, so even though I had no log entries I tried setting the ownership of /tmp/ufs to root:www-data and perms to 775, and now it works! Thank you so much! I wonder if it's because Rocket.Chat was first run as root and it made the directory itself? This seems related:
We also happen to have a "non working upload" sometimes. What it comes down to is that rocket.chat creates /tmp/ufs on start and then never again. When tmpwatch finds the old directory a few days later it happily removes it. Rocket.chat fails then with ufs: cannot write chunk of file "tTeMYrLLjYZ6Dk2tM" (ENOENT: no such file or directory, open '/tmp/ufs/tTeMYrLLjYZ6Dk2tM')
. It would be helpful to create the directory before use, if it's not there. Or make it configurable to a location where it will not be removed by system cleanup jobs.
i have a same issue.
i run multiple rocketchat 0.58 instance at root folder not a sub folder.
This one is getting a bit old with no new posts.
Going to go ahead and close this.
Feel free to move discussion to forum in the community support category
Most helpful comment
We also happen to have a "non working upload" sometimes. What it comes down to is that rocket.chat creates /tmp/ufs on start and then never again. When tmpwatch finds the old directory a few days later it happily removes it. Rocket.chat fails then with
ufs: cannot write chunk of file "tTeMYrLLjYZ6Dk2tM" (ENOENT: no such file or directory, open '/tmp/ufs/tTeMYrLLjYZ6Dk2tM')
. It would be helpful to create the directory before use, if it's not there. Or make it configurable to a location where it will not be removed by system cleanup jobs.