5

I have a problem with a ubuntu-instance (Ubuntu 20.04.1 LTS) and apache2 (Apache/2.4.41 (Ubuntu)). One virtual-host is serving some html-files and documents from a mounted cifs-share. The cifs-share is working normally, files are correct on filesystem.

However, the apache fails to generate proper responses for every filetype which is served in binary (like images, word-documents, pdfs, ...). For example, when I download an image image.gif the file is downloaded and saved to the client. When opening the file with a text-editor on the client it looks as followed:

grade, Keep-Alive
Last-Modified: Thu, 12 Nov 2020 10:01:47 GMT
ETag: "b6b-5b3e600040144"
Accept-Ranges: bytes
Content-Length: 2923
Keep-Alive: timeout=5, max=100
Content-Type: image/gif

GIF89av[binary-string starting...]

So a part of the response-headers are now in the downloaded file, which should never happen. I am expecting the downloaded file starting with GIF89av and so on. Serving text-based files (like html) is not a problem and works as expected. However, when I copy the same file into the document-root of another virtual-host on the same server which does not use the mounted cifs-share, the file is served correctly (without response-headers in it). So I assume, that there is some problem in this combination of mounted cifs-share and apache2, which leads to that error.

I already tried various options regarding the mount of the share - but that is correct in my opinion, since the files are working directly on the filesystem without apache.

The share is mounted in /etc/fstab as followed

//192.168.0.1/share$ /mnt/share cifs username=user,password=pass,dom=contoso.local 0 0

which is pretty much the most basic way to do it. I experienced with options like iocharset=utf8, tried different versions (vers=1.0 or vers=3.1) but that didn't change anything. The apache-configuration is also the basic one, shipped with ubunutu 20, nothing special added or changed there. I experienced a bit with the mime-types, but apache should be cappable of serving an image out of the box.

Additionally I started a php-webserver (php -S 192.168.0.2:8000) for testing in that directory - that returns correct binary-files which makes me pretty sure, that the error is somewhere in apache.

What is leading to this corrupt responses from apache and how can I fix it?

3 Answers 3

4

I am having the same issue, it seams this issue is recent, possibly related to kernel version in 20.04? I do see the issue with plain text files as well. Were you able to find a solution / workaround? (Sorry I do not have the rep to post a comment)

Edit: I was able to find a bug report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900821 Setting EnableMMAP off in the apache config worked for me:

EnableMMAP off
3
  • 1
    Thanks, that setting seems to fix that. However, after passing several hours in that problem, we switched to nginx on that server, which solved the problem.
    – cklm
    Commented Dec 23, 2020 at 10:47
  • I wish I had found this answer 30 hours ago. It would have saved me ... 30 hours. As of this date, it is definitely a bug in apache distributed with Ubuntu 20 LTS. It is not a problem with Ubuntu 18 LTS
    – pdwalker
    Commented Nov 12, 2021 at 9:04
  • to globally fix this I created a file in /etc/apache2/conf-enabled called mmap.conf and just added "EnableMMAP off" as a single line in the file to disable it for all virtual hosts.
    – pdwalker
    Commented Nov 12, 2021 at 9:06
2

In "/etc/apache2/apache2.conf", add:

EnableSendfile Off
EnableMMAP off

This saved my life~

1
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Jan 13, 2022 at 23:46
0

The second answer with both EnableMMAP off and Enable Sendfile Off seems to have fixed the issue for me.

This directive controls whether httpd may use the sendfile support from the kernel to transmit file contents to the client. By default, when the handling of a request requires no access to the data within a file -- for example, when delivering a static file -- Apache httpd uses sendfile to deliver the file contents without ever reading the file if the OS supports it.

Turning this off removes the possibility of different or not working functionality in the kernel sendfile call causing issues.

This was an issue for RHEL 8 4.18.0-305.3.1.el8_4.x86_64

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .