Recently unable to mount Windows 2012 Server network drives

[TheFu]

Can you (please) point in the direction (on the linux side) as to what logs I need to look at? Is there another share type I can use on the windows server that interfaces better with linux?

NFS, but I don't know about it being "better" when Windows is involved. userid mapping will need to be handled, which is usually a manual thing to setup IME.

NFS is server-to-server, not user-to-server.
Perhaps I missed whether Kerberos authentication was being used or not.

I'm just asking questions in hope that it may spawn ideas in others. I've never connected any Linux system to any Windows Server using file sharing.

The closest was in the mid-1990s when we used NFS on Windows Server with thousands of Unix clients (machines and about 6K users) due to political reasons. Windows was a political choice due to some other MSFT agreements at that location.

[darkod]

If it was the other way around (windows is the client) I would say NFS too. Especially since recent versions of Windows now include NFS client by default.

But I am not sure if Windows can serve as NFS server and if it can be trusted for that role. It's worth exploring though.

[TheFu]

Windows Server used to have the Unix Services pak. Thought that was discontinued.

We used 3rd party NFS tools, which were not cheap.

I've never gotten NFS working from WinXP, Vista, Win7 after multiple attempts. That includes a Win7 Ultimate license (a gift from MSFT). Windows Home has never included NFS, so if Win10 does, that's great, new and news. There are free NFS clients that I've seen. They were all shareware to my knowledge or hadn't been maintained in 5+ yrs. I'd love to be wrong. It wouldn't be the first time.

[darkod]

Yeah, I was speaking only about native tools, not third-party. The NFS Client comes as Windows feature now, and disabled. You only have to enable it.

Again, I'm not sure any of this helps if you want Window to be the one serving the share. CIFS/SMB still seems the only way to go for that.

[TheFu]

CIFS/SMB still seems the only way to go for that.

Yep - 98% of the time, CIFS is the better answer when Windows is involved.

I had an issue connecting to Win7 (I don't have anything newer here) in my hacking lab. Made all sorts of changes and couldn't get Win7 to share anything. Finally, on a weekly Linux meeting, I asked for help. They asked, "have you tried turning it off and on again?"

Flashbacks to Roy and Moss ...

It worked. How sad is that?

[Morbius1]

This my be way off base but is it all possible you enabled SMB encrypted transport at either the share level or the server level in your Win2012 server?

If you did specifying vers=2.1 will not work. Even if you told mount.cifs to force encrypted transport it will not work. It can only be done when using SMB3.

If you remove the vers=2.1 from your mount declaration it should go SMB3 by itself. If not specify vers=3.0 in your mount command.

[linuxnoob87]

xxxx@PlexServer:/mnt$ sudo mount -t cifs -vvv //HServer/HPics /mnt/HPhotos -o user=(Username@domain.global),password=(Password),sec=ntlm 
[sudo] password for xxxx: (Password typed here)
mount.cifs kernel mount options: ip=172.16.249.101,unc=\\HServer\HPics,sec=ntlm,user=xxx@domain.global,pass=********
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

/var/log/syslog:

Sep  5 22:41:38 PServer kernel: [558863.327821] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
Sep  5 22:41:38 PServer kernel: [558863.329183] CIFS VFS: Unable to select appropriate authentication method!
Sep  5 22:41:38 PServer kernel: [558863.329185] CIFS VFS: Send error in SessSetup = -22
Sep  5 22:41:38 PServer kernel: [558863.329908] CIFS VFS: cifs_mount failed w/return code = -22

[linuxnoob87]

Here's my mount line in the fstab file:

//HServer/HPics /mnt/HPhotos cifs user=(domain user name),password=(password),iocharset=utf8,vers=3.0  0  0

Note that prior to 5 minutes ago the vers=3.0 was set to vers=2.1. Removing any reference to a version doesn't mount the drive either (using "sudo mount -a")

I know that putting the password directly in the fstab file is not great; this is a home environment where I'm not worried about passwords "leaking".

Thank you all for your help and assistance. What's weird (but I'm happy about) is that connectivity to Server 2016 is still working properly.

Edit: Interestingly enough I can mount the share via the GUI from my Linux Mint 20 (Ulyana base: Ubuntu 20.04 focal) laptop

[darkod]

First, make sure cifs-utils is installed. You can check that with:

apt-cache policy cifs-utils

Then, you said the server is not joined in a domain but for the credentials in mount you use a domain user???

Have you also tried creating local user on the server and use that one?

I am pretty sure this is because of something on the windows side, especially since you use domain user and maybe all you need to do is play with the sec= options. From the man page of mount.cifs:

none attempt to connection as a null user (no name)
krb5 Use Kerberos version 5 authentication
krb5i Use Kerberos authentication and forcibly enable packet signing
ntlm Use NTLM password hashing (default)
ntlmi Use NTLM password hashing and force packet signing
ntlmv2 Use NTLMv2 password hashing
ntlmv2i Use NTLMv2 password hashing and force packet signing
ntlmssp Use NTLMv2 password hashing encapsulated in Raw NTLMSSP message
ntlmsspi Use NTLMv2 password hashing encapsulated in Raw NTLMSSP message, and force packet signing

We are not in a position to judge what do you need for the domain user to authenticate successfully especially since you said the server is not joined to the domain but you use domain credentials for the share. That is how I understood it and I find it very strange.

If the server is not in a domain you would use local user.

[TheFu]

For not putting username and password into the fstab, use:

       credentials=filename
           specifies a file that contains a username and/or password and
           optionally the name of the workgroup. The format of the file is:

                         username=value
                         password=value
                         domain=value

           This is preferred over having passwords in plaintext in a shared
           file, such as /etc/fstab. Be sure to protect any credentials file
           properly.