Ok. "Good" news. The issue is specific to vers=2.0. Testing against a newer DFS target $ nmap -P0 -p 445 --script smb-protocols other.dfs.target Starting Nmap 7.70 ( https://nmap.org ) 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://nmap.org ) 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_interval=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
