
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.gif
o 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 GIF89av
e 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/fstab
seguinte 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.0
ou 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