Windows Server 2016 Mount Iso Not Working
Oleta Blaylock
I have recently been testing and working through some scenarios where I require the NFS client on a Windows machine to access some NAS shares over the NFS protocol, not much has changed I believe between Windows Server 2016 and Windows Server 2019 but thought it might help some to see how easy it is to get going.
I am pretty sure this could also be achieved through the system manager and selecting the Add Features dialog and working through the wizard approach, I have been purposely doing a lot more of my tasks through PowerShell so that I can re-use and make my tasks quicker, this is something I have picked up from my learnings around Infrastructure as Code. For that reason, I am using PowerShell. I am sure someone else had documented the process through the system manager and UI.
As I said before I am using Azure NetApp Files, this export is configured in the following screen when configuring Azure NetApp Files. I will provide a step by step walkthrough of this process after this initial post.
As you can see from the above, I have allowed all clients from all subnets using the export policy (This is the default setting for ANF), my advice is that if this was production you should to create more secure export policies.
Some people will ask now, why you are using NFS when you can use SMB, certain applications, certain environments may require this method and protocol. If this was a traditional Windows environment and this share was going to house predominately user shares and home drives, then absolutely the way to do this would most likely be with the SMB protocol.
Next up is open up a command prompt with Administrator privileges, the mount command is going to be the command you use and then you will be using the NAS IP Address followed by the share name and then which letter you would like to mount this to on your Windows system.
Providing you have the correct configuration, mostly down to the export policy on your NAS device then this process should take seconds. And then by seeing the success message as per above but then checking this now as a mapped network drive as per below.
Quick post hope that it is useful for somebody. This was something I was working on so that I could test Azure NetApp Files without access to Azure Active Directory services (due to corporate policy) this stopped me from being able to use SMB but allowed me to test the functionality via NFS on Windows and Ubuntu.
On archlinux after a recent package update, I had to add vers=1.0 to my mount options. I'm connecting to an old centos 5 box and up until yesterday I could connect without explicitly stating a version number.
I have an antivirus with a firewall and even though I set it explicitly to allow "windows file and print sharing" -- a predefined rule, it was still blocking connections. I had that proven by disabling the firewall temporarily.Hope this helps someone, host is down might not mean it's not responding to pings, but could mean it's not responding to authentication attempts.
However, if the server that you are connecting to uses DFS, then you will get the following error instead: mount error(38): Function not implemented. This is because DFS support on SMB3 was only added to the kernel in version 4.11.
For me, the mounted cifs share was on a Windows server whose IP address had changed recently, so I could ping the server and resolve its new address, but the mount had not updated itself. By running a lazy unmount and then re-mounting my issue was solved:
Specifically, I'm using vers=2.0, but my Synology Diskstation was triggering the Host is down error. I found a page, Windows 10 access to NAS share. SMB 1.0 and 3.0, on the Synology website that explained how to set the Diskstation to allow SMB v2.0 or newer...
In our case I checked the users login name (of user2) in the AD. There I noticed that the name was starting with an upper case letter and changed it to lower case as it is written in the mount script. Even if we did not touch neither user2 nor the mount script before, suddenly the mount command was successful.
I also just ran into the problem mentioned after an upgrad to Xubuntu 17.10. I use a Synology DiskStation.What I saw there: In the DiskStation, you can choose which protocols to support. By adding he relevant protocols (up to SBM3) in the advanced options for file services in control panel, you can also solve the problem.
Had a similar problem. The solution for me was on the Windows share server side. Even passing the value vers=2.0 to my Linux server, the mount wasn't working. So I had to enable on my Windows server smbv1 support. This article helped me: -us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and
I faced the same issue and after following steps mentioned in a blog, i am able to share files/directory between windows host and docker container. Here is the link to that blog -on-windows-mounting-host-directories-d96f3f056a2c
Then I run the command again and Docker asked about permissions again. I answered yes and it forced me to re-enter my domain password. After this, I was able to view contents of a mounted folder. I think, that I initially allowed sharing with another domain password (expired now) and Docker cannot handle such situations.
1- Go to the folder you want to access
2- Properties -> Security -> Modify -> Add -> YourMachine\docker-users (you can check via the nearby button) or search with the advanced button the docker-users group
This is due to the access control by default on Windows 10, even if your are logged and your credentials are good, you are not a real administrator of the system. So i think the rights does translate to docker-users as local user which has not the permissions required.
So glad I found this thread. After banging my head for a day, I can confirm this on windows server 2016 running docker 18.03ce. Any special characters in the password for the shared volume, makes it fail, & the container cant access it.
Is port 111 open in the firewalls?
The NFS client does an rpc call on port 111 (rpcbind/portmap) first.
There it gets two more ports, for nfs and mount
Also these must be open in the firewalls.
Good observation, only one backslash was visible.
Now I have edited the initial post, and wrapped the command in triple-backticks markdowns. And the double backslash shows up.
@nitrox2000, use the icons ICode(Inline Code) and Code(Code Block) at the top of the editor window!
No, as the 2008 server was in Production a new replacement 2019 box was built, configured and tested using a fixed disk to replicate the mounted AIX drive, using a new hostname and IP address. Then a cutover was planned and the fixed disk removed and FW rules duplicated to match the current server. The problem was pre-cutover the drive wouldn't mount so delayed the change.
It took another admin to perform a TCPDump and you could see traffic from the new server hitting AIX box but not getting back to the Window box.
Then the host file was checked and it contained an entry for the current Prod 2008 boxes hostname (FQDN), so the new 2019 server hostname (FQDN) was added and the mount command worked immediately.
Anyway - in my case the issue was unique to the software that handles SMB/CIFS mounts (network drives typically) from fstab. As it turns out, there are several versions of SMB; you can see a list of these in man mount.cifs. And - at least in my case - getting the correct version was crucial to a successful mount (consummation? :).
It's still painful to recall (mostly due to how my bug report was handled), and AFAIK it's still buggy. The point of this post is only my effort to raise awareness that when it comes to SMB mounts - version matters.
You may be wondering how to determine the SMB protocol version (I did). On a Windows machine, that is said to be available from the "Power Shell" using the command: Get-SmbConnection. On a Linux server (Samba), this should work: sudo smbstatus. If you're using a network appliance (as I am) as a SMB/CIFS file server, you may have to resort to trial-and-error.
I am using VMware Player to run a Windows 2012 Server Standard Build 9200. I need to mount an ISO image. The server does not seem to recognize that it is an ISO file and wants me to tell it how to open it. I know I could install a third-party application, but Windows 2012 already supports this feature.
Worked for me with a SharePoint Online UNC path. The permissions are screwy though. I can navigate through the folders and see the filenames, but I can't read files. So need to figure out the permissions thing. Let me know if you get anywhere with that.
Nothing too hard, the source path of the mount is the regular UNC pathname. The important bits are the file system type ("drive filesystem"?) and the fact that you need to enclose the server path in single quotes (on the command line). As usual, your mount folder must also exist.
Note that I have logged into the server on Windows itself and made it remember the user and password. @David C. Rankin's answer has some info on how to specify username and password if you need to do it separately.
While you have an a mount created to the windows host through /mnt/c already created for you in WSL, if you want to mount a share from another machine, then you will need to create the mount point, e.g.
If it is an older WinXP share you are attempting to mount, then you will need to enable NTLMv1 authentication by including the sec=ntlm or sec=ntlm1. See mount.cifs for further use of the sec= option.
In WSL (I'm using Ubuntu) it looks like that when you install the cifs-utils it doesn't create the module file that cifs needs when mounting. Type: "modinfo cifs" and you will see. Anyway, the work-around is to map a drive letter in Windows and then mount to that, as mentioned above. Thanks gabuzo.
Client with Server 2019 Standard. Had a drive fail in RAID 5 array (which shouldn't have caused corruption, but it did). I had to rollback/restore registry hive including COMPONENTS from prior to any corruption. This rolled it back to Dec. 15 2022 timeframe, whereas drive and corruption occurred between this date and Jan. 1 2023. Server works fine, minus seeing that I can't run Windows update, it fails it can't connect to update service, as though not connected for internet (server has full internet access, shows that status AOK, however also has strange issue showing "Not connected" to any networks in the Network & Internet overview.
d3342ee215