Outlook and Zimbra Connector not sending attachments

[mmorse]

Welcome to the forums,
Several posts in this thread mention a few things we're fixed for 5.0.3+
Could you update and see if your issue still persists?
5.0.5 is Released!

[Petrus.Rossouw]

Same problem with 5.0.10

can not send attachment larger than 135k, it seems.

[mikelcu]

Looks like this is happening to a couple of my users as well on 5.0.9. Can't say if their issue is related to size, but we're getting unexplained timeouts:

2008-11-20 20:27:13,815 INFO  [btpool0-5416] [name=user@domain.com;mid=179;ip=10.80.9.29;ua=Zimbra-ZCO/5.0.2706.9 (5.1.2600 Service Pack 3;; ja-JP);] FileUploadServlet - File upload failed
org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. null
    at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:429)
....

This is happening almost exclusively to my users in Japan, but aside from their location, I can't see any difference between their setup and anyone else's...

-Mike

[fultonj]

I still have it (5.10).

2008-12-30 11:40:33,738 INFO [btpool0-1373] [name=reichs@lafayette.edu;mid=3751;ip=139.147.48.2 26;ua=Zimbra-ZCO/5.0.2767.10 (5.1.2600 Service Pack 2;; en-US);] FileUploadServlet - File upload failed

Left 2 VMs with Support. Waiting ... Half my users are out of commission. Any ideas? Anyone?

[fultonj]

If you see the errors described above check your inodes. What does 'df -i' return?

Support got back to me and we found that /opt/zimbra had run out of inodes.

We ran out of inodes because convertd was choking on winmail.dat files
from the past from the imapsync. had to bring zimbra down to clean them
out. remount and bring it back up. convertd has been disabled until the
import is done. This means webmail searches won't return new attachments
for now.

[Jrtbloke]

I'm having this issue with 6.0.2 and outlook clients - could one of the zimbra staffers give us unix noobs a step by step to the fix fultonj mentions here? some advisory on any repercussions would also be good.

[fultonj]

jrtbloke

To see if we have the same problem simply run 'df -i' and see if you have run out of inodes, which are a file system thing, not a Zimbra thing (google it if you are not sure). If you ran out, then delete files. In my case attachment indexing made too many so I cd'd to that directory and did an 'rm *' (make sure you're in the right directory

[Jrtbloke]

ahhhh - i'm on OSX not linux, which folder within the zimbra root holds the indexed attachments?

[fultonj]

Jrtbloke

OS X uses inodes too (it's a Unix file system thing, and OS X's HFS+ is unix like). Please post the output of 'df -i' and we'll see if you're full or not before bothering to find the relevant directory.

John

[Jrtbloke]

thanks

the output is: (formatting is screwy so ive attached the txt file as well)

zimbra:~ root# df -i
Filesystem 512-blocks Used Avail Capacity iused ifree %iused Mounted on
/dev/disk0s2 976101344 351285760 624303584 36% 43974718 78037948 36% /
devfs 188 188 0 100% 562 0 100% /dev
fdesc 2 2 0 100% 4 253 2% /dev
<volfs> 1024 1024 0 100% 0 0 100% /.vol
automount -nsl [238] 0 0 0 100% 0 0 100% /Network
automount -fstab [267] 0 0 0 100% 0 0 100% /automount/Servers
automount -static [267] 0 0 0 100% 0 0 100% /automount/static
zimbra:~ root#