Apache2 envia respostas corrompidas ao usar um compartilhamento cifs

Apache2 envia respostas corrompidas ao usar um compartilhamento cifs

Eu tenho um problema com uma instância do Ubuntu (Ubuntu 20.04.1 LTS) e Apache2 (Apache/2.4.41 (Ubuntu)). Um host virtual está servindo alguns arquivos html e documentos de um compartilhamento cifs montado. O cifs-share está funcionando normalmente, os arquivos estão corretos no sistema de arquivos.

No entanto, o Apache não consegue gerar respostas adequadas para cada tipo de arquivo servido em binário (como imagens, documentos do Word, PDFs, ...). Por exemplo, quando faço download de uma imagem, image.gifo arquivo é baixado e salvo no cliente. Ao abrir o arquivo com um editor de texto no cliente fica assim:

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...]

Portanto, parte dos cabeçalhos de resposta agora está no arquivo baixado, o que nunca deveria acontecer. Estou esperando o arquivo baixado começando com GIF89ave assim por diante. Servir arquivos baseados em texto (como html) não é um problema e funciona conforme o esperado. No entanto, quando copio o mesmo arquivo na raiz do documento de outro host virtual no mesmo servidor que não usa o compartilhamento cifs montado, o arquivo é servido corretamente (sem cabeçalhos de resposta). Então presumo que haja algum problema nesta combinação de cifs-share montado e apache2, o que leva a esse erro.

Já tentei várias opções quanto à montagem do compartilhamento - mas na minha opinião está correto, pois os arquivos estão funcionando diretamente no sistema de arquivos sem apache.

O compartilhamento é montado da /etc/fstabseguinte forma

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

que é praticamente a maneira mais básica de fazer isso. Experimentei opções como iocharset=utf8, tentei versões diferentes ( vers=1.0ou vers=3.1), mas isso não mudou nada. A configuração do apache também é a básica, fornecida com o ubunutu 20, nada de especial adicionado ou alterado lá. Eu experimentei um pouco com os tipos MIME, mas o Apache deve ser capaz de exibir uma imagem pronta para uso.

Além disso, iniciei um php-webserver ( php -S 192.168.0.2:8000) para testar nesse diretório - que retorna arquivos binários corretos, o que me dá certeza de que o erro está em algum lugar do Apache.

O que está levando a essas respostas corrompidas do Apache e como posso consertar isso?

Responder1

Estou tendo o mesmo problema, parece que esse problema é recente, possivelmente relacionado à versão do kernel em 20.04? Também vejo o problema com arquivos de texto simples. Você conseguiu encontrar uma solução/solução alternativa? (Desculpe, não tenho representante para postar um comentário)

Editar: consegui encontrar um relatório de bug aqui: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900821 Desativar o EnableMMAP na configuração do Apache funcionou para mim:

EnableMMAP off

Responder2

Em "/etc/apache2/apache2.conf", adicione:

EnableSendfile Off
EnableMMAP off

Isso salvou minha vida ~

Responder3

A segunda resposta com EnableMMAP desativado e Enable Sendfile desativado parece ter resolvido o problema para mim.

Esta diretiva controla se o httpd pode usar o suporte sendfile do kernel para transmitir o conteúdo do arquivo ao cliente. Por padrão, quando o tratamento de uma solicitação não requer acesso aos dados dentro de um arquivo - por exemplo, ao entregar um arquivo estático - o Apache httpd usa sendfile para entregar o conteúdo do arquivo sem nunca ler o arquivo se o sistema operacional suportar.

Desativar isso elimina a possibilidade de funcionalidades diferentes ou que não funcionam na chamada sendfile do kernel, causando problemas.

Este foi um problema para RHEL 8 4.18.0-305.3.1.el8_4.x86_64

informação relacionada