> -----Original Message----- > From: linux-cifs-owner@xxxxxxxxxxxxxxx <linux-cifs-owner@xxxxxxxxxxxxxxx> On > Behalf Of Robin P. Blanchard > Sent: Thursday, August 16, 2018 3:34 PM > To: Steve French <smfrench@xxxxxxxxx> > Cc: linux-cifs@xxxxxxxxxxxxxxx > Subject: Re: regression in CIFS(?) between 4.17.14 and 4.18.0 > > Ok. "Good" news. > > The issue is specific to vers=2.0. Your Windows Server 2008R2 target supports SMB2.1, is there some reason you are not using the 2.1 dialect? It is *much* preferred to the baselevel 2.0, though of course any 3.x is better still. Tom. > > > > Testing against a newer DFS target > > $ nmap -P0 -p 445 --script smb-protocols other.dfs.target > Starting Nmap 7.70 ( > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnmap.org > &data=02%7C01%7Cttalpey%40microsoft.com%7Cff765403f203480385b > 208d603af3a3e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367 > 00448466765548&sdata=CE4dYLsKILO5bSZKEzsL9SPYJF%2BBZBLn%2BriO > d6GRX44%3D&reserved=0 ) at 2018-08-16 16:30 ADT > Nmap scan report for other.dfs.target (y.y.y.y) > Host is up (0.00049s latency). > > PORT STATE SERVICE > 445/tcp open microsoft-ds > > Host script results: > | smb-protocols: > | dialects: > | 2.02 > | 2.10 > | 3.00 > | 3.02 > |_ 3.11 > > Nmap done: 1 IP address (1 host up) scanned in 0.35 seconds > > vers=3.0 works as expected, vers=3.02 works as expected, vers=2.0 > triggers spontaneous reboot. > > > On Thu, Aug 16, 2018 at 2:22 PM Robin P. Blanchard > <robin.blanchard@xxxxxxxxx> wrote: > > > > The backend DFS target server (Microsoft Windows Server 2008 R2 > > Enterprise) only supports version=2 > > > > $ nmap -p 445 --script smb-protocols dfs.ad.domain > > Starting Nmap 7.70 ( > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnmap.org > &data=02%7C01%7Cttalpey%40microsoft.com%7Cff765403f203480385b > 208d603af3a3e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367 > 00448466765548&sdata=CE4dYLsKILO5bSZKEzsL9SPYJF%2BBZBLn%2BriO > d6GRX44%3D&reserved=0 ) at 2018-08-16 15:59 ADT > > Nmap scan report for dfs.ad.domain (x.x.x.x) > > Host is up (0.00045s latency). > > > > PORT STATE SERVICE > > 445/tcp open microsoft-ds > > > > Host script results: > > | smb-protocols: > > | dialects: > > | NT LM 0.12 (SMBv1) [dangerous, but default] > > | 2.02 > > |_ 2.10 > > > > Nmap done: 1 IP address (1 host up) scanned in 0.37 seconds > > > > > > Booting test VM back into 4.18.1-1.el7.elrepo.x86_64 (with all CIFS > > debugging enabled)... > > > > vers=1.0 (known to be disabled) results in: > > > > mount error(112): Host is down > > > > which is expected. > > > > vers=2.0 triggers the spontaneous reboot. Nothing captured in > > syslogs/dmesg. The command isn't even in the shell's history post > > reboot. > > > > I'll keep digging.... > > > > On Thu, Aug 16, 2018 at 1:55 PM Steve French <smfrench@xxxxxxxxx> > wrote: > > > > > > If we can get some data from dmesg (location of oops) to narrow this down > that would help - perhaps would have to build with different options, but in the > meantime if anyone else is able to repro this or you get more data on this let us > know ASAP > > > > > > It is very suspicious to mount with vers=2.0 (e.g. Windows Vista) as that is > the least tested and used. Any idea if you see this with normal default (3.0 or > 3.02 would be the most commonly supported by servers these days with > default mounts from Linux). > > > > > > On Thu, Aug 16, 2018 at 1:47 PM Robin P. Blanchard > <robin.blanchard@xxxxxxxxx> wrote: > > >> > > >> Apologies in advance for not having a better troubleshooting approach. > > >> I'm at a loss... > > >> > > >> I maintain a large number of CentOS 7 based machines that utilize > > >> pam_mount to service (CIFS) user homedirs. This has worked swimmingly > > >> for many years. I recently rebooted a test node into both kernels > > >> 4.18.0 and 4.18.1 to find that upon user login (the triggering of > > >> pam_mount of CIFS homedir -- eg, local users/homedirs do not trip the > > >> problem), the kernel spontaneously reboots :/ Roll back to 4.17.4 and > > >> all is well again. Further strang-ifying things, is that static CIFS > > >> mounts (via /etc/fstab) _do_ mount as expected in 4.18.x. > > >> > > >> functional state: > > >> > > >> $ cat /etc/redhat-release > > >> CentOS Linux release 7.5.1804 (Core) > > >> > > >> $ uname -r > > >> 4.17.14-1.el7.elrepo.x86_64 > > >> > > >> $ rpm -qa |grep pam_mount > > >> pam_mount-2.16-5.el7.x86_64 > > >> > > >> $ grep "$(whoami)" /proc/mounts > > >> //dfs.ad.domain/path/to/USER /home/ad.domain/USER cifs > > >> > rw,relatime,vers=2.0,sec=krb5i,cache=strict,username=user,domain=ad.domain, > uid=MYUID,forceuid,gid=MYGID,forcegid,addr=dfs.target.ip,file_mode=0700,dir > _mode=0700,soft,nounix,serverino,mapposix,rsize=65536,wsize=65536,echo_in > terval=60,actimeo=1 > > >> 0 0 > > >> > > >> > > >> Given that the static mounts (which use ntlmsspi) work fine (in > > >> 4.18.x) i, I thought I'd return the user homes back to ntlmsspi; but > > >> the spontaneous reboot is still triggered. > > >> > > >> Any ideas how I might better troubleshoot this? Or is this possibly > > >> pam_mount somehow tickling the newer kernels in a bad way? > > >> > > >> Thanks in advance > > > > > > > > > > > > -- > > > Thanks, > > > > > > Steve
