4.18.6 stable release is out (and includes 9 cifs/smb3 fixes including this one) - let me know if that doesn't fix the problem. On Sat, Sep 1, 2018 at 12:07 AM Steve French <smfrench@xxxxxxxxx> wrote: > > Looks like 4.18.6 stable will have the fix we wanted you to try > (looking at their tree in kernel.org). That stable kernel should be > out pretty soon given that it has been in rc for days > 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 > > > > -- > Thanks, > > Steve -- Thanks, Steve
