[Samba] CIFS VFS: in dmesg when Linux accesses eComStation's (OS/2) FAT filesystem shares

[Felix Miata]

Jeremy Allison via samba composed on 2020-04-24 11:13 (UTC-0700):

> On Fri, Apr 24, 2020 at 04:31:53AM -0400, Felix Miata via samba wrote:

>> Jeremy Allison via samba composed on 2020-04-23 09:24 (UTC-0700):

>> >> CIFS: Attempting to mount //hostname/E
>> >> Use of the less secure dialect vers=1.0 is not recommended unless required for
>> >> access to very old servers
>> >> CIFS VFS: Send error in QFSAttributeInfo = -95

>> >> /etc/fstab entry for //hostname/E:
>> >> //hostname/E /smbmnt/hostname/E cifs
>> >> ro,credentials=/etc/samba/hostname.cred,sec=lanman,vers=1.0,servern=HOSTNAME,domain=MYHOST,port=139,dir_mode=0555,file_mode=0664,noserverino,noauto
>> >> 0 0

>> >> Kernel, Samba and CIFS client versions:
>> >> Linux 00srv 4.12.14-lp151.28.44-default #1 SMP Fri Mar 20 18:20:20 UTC 2020
>> >> (dbf1aea) x86_64 x86_64 x86_64 GNU/Linux
>> >> cifs-utils-6.9-lp151.4.3.1.x86_64
>> >> samba-4.9.5+git.296.3dd62eee45e-lp151.2.21.1.x86_64
>> >> samba-client-4.9.5+git.296.3dd62eee45e-lp151.2.21.1.x86_64

>> >> What needs to be done to quiet dmesg when these file access occur? These didn't
>> >> occur until some not all that recent updates to Samba/CIFS versions, maybe a year
>> >> or more, I'm not sure, but ISTR once upon a time complete silence from such touches.

>> > Can you send in a wireshark trace of the client talking to
>> > the OS/2 server ?

>> Haven't used Wireshark in over a decade. I hope this is what you want.
>> http://fm.no-ip.com/Tmp/Linux/Samba/jra-samba04.trace.pcapng

> Looking at that trace the client is doing a QPATHINFO request
> (SMBtrans2 request) with level 263 - Query File All Info.

> The OS/2 server doesn't support that, so the client then
> drops back and does a SMB1 Query Information Request (SMB1
> request 0x8, what Samba calls SMBgetattr).

> This doesn't have the links or expanded time information
> (it only returns one date) so the client isn't then able
> to synthesize this information.

> Also the client isn't caching the fact that the server
> doesn't understand SMBtran2:QPATHINFO:263 and so it
> keeps issuing these and doing the fallback on every
> query. This will significantly damage performance.

Whose performance, client's? Server's? Both? Only between the two? Do you have an
recommendations that don't involve abandoning the only acceptable means to keep
(OS/2 for) running my (constantly used) DOS orphan apps that have never had any
upgrade path?
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/