Hi,
maybe I found something new?
I was facing the same problem as discussed here. Windows share mounted from
RHEL 8.3 using Oracle OHS Apache, serving static ZIP file on that shared disk.
According to hexdump, HTTP response headers were corrupted by some random
binary data.
Our case:
* RHEL 8.3 client with Oracle OHS (Apache) using
* Windows FS cluster.
/etc/fstab on the client uses just:
credentials=/root/somefile.txt,uid=1000,gid=1000
Real (anonymized) mount options (mount | grep cifs):
//xxx.xxx.xxx.xxx/yyy on /some/folder type cifs
(rw,relatime,vers=3.1.1,cache=strict,username=oracle,domain=my.priv,uid=1000,forceuid,gid=1000,forcegid,addr=xxx.xxx.xxx.xxx,file_mode=0755,dir_mode=0755,soft,persistenthandles,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1)
Problem occurs when CIFS share is mounted to mentioned Windows share cluster.
But I was unable to reproduce it when CIFS share was hosted on Ubuntu 20.04.3
LTS instead. I've limited access to the non-Ubuntu environment, so I'm
currently unable to experiment more on this.
The only difference I found was the "persistenthandles" usage in Windows share
case. Hope this may help finding the root cause.
We're about to use the "EnableMMAP off" workaround anyway.
Regards
Rostislav
Samba server Ubuntu 20.04.3 LTS => works OK even without "EnableMMAP off":
* 5.4.0-74-generic
* samba: 2:4.11.6+dfsg-0ubuntu1.10)
Client RHEL 8.3:
* 4.18.0-240.8.1.el8_3.x86_64
* Apache: Oracle-HTTP-Server-12.2.1.4.0/2.4.39 (Unix)
* cifs-utils-6.8-3.el8.x86_64
____________________________
Powered By Office365
The information contained in this communication is intended solely for the use
of the individual or entity to whom it is addressed and others authorized to
receive it.
It may contain confidential or legally privileged information.
If you are not the intended recipient you are hereby notified that any
disclosure, copying, distribution or taking any action in reliance on the
contents of this information is strictly prohibited and may be unlawful.
If you have received this communication in error, please notify us immediately
by forwarding this email to mailad...@ness.com<mailto:mailad...@ness.com> and
then delete it from your system.
Ness technologies is neither liable for the proper and complete transmission of
the information contained in this communication nor for any delay in its
receipt.
