samba - Apr 2020 - CIFS VFS: in dmesg when Linux accesses eComStation's (OS/2) FAT filesystem shares

Jeremy Allison via samba composed on 2020-04-23 09:24 (UTC-0700):
> On Thu, Apr 23, 2020 at 02:59:18AM -0400, Felix Miata via samba wrote:
>> Items in dmesg when FAT share's are accessed from web browser:
>> CIFS VFS: bogus file nlink value 0
> nlink should never be zero. If an SMB server
> returns that, then the CIFSFS client will have
> to fake it to 1 at least.
>> When accessed from FC/L (OFM (orthodox filemanager)):
>> CIFS VFS: illegal date, month 0 day: 0
>> When the share is initially mounted:
>> 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
-- 
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/

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.

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/