NAS drive will not mount on some WSL2 systems

Question

The same commands for mounting a NAS drive have completely different results. I have data from two computers, both are WSL2 and Windows 11.

The only clue I've come up with is the updated Linux kernal (5.15) in the system that doesn't work like the others.

Looking at the Linux "mount" docs, "drvfs" isn't a valid type value, yet it's been working for years on the other systems, including WSL1.

Other than understanding what is going on, my goal is to detect which systems need which command. The "MUSICCOMP-3020" is the new one and the only one that doesn't work with the "-t drvfs". I run a Python program to mount the NAS on these and a couple of other systems, so need to reliably detect which command to use, or find a command that works on all WSL2 installations.

The captured data follows. It is showing the responses same two commands on the two computers: "MUSICCOMP-3020" and "XPS8950".

======================================

On MUSICCOMP-3020:

uname -a

Linux MUSICCOMP-3020 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

This works:

 sudo mount -t cifs -o guest,uid=1000,iocharset=utf8 //192.168.2.202/EX2Ult /mnt/ex2ult

This fails:

 sudo mount -t drvfs -o rw,noatime,uid=1000,gid=1000 '\\192.168.2.202\\EX2Ult' /mnt/ex2ult

The error response is:

<3>WSL (564) ERROR: MountWithRetry:307: mount(drvfs, /mnt/ex2ult, 9p, 0x00000400, cache=mmap,msize=262144,trans=virtio,aname=drvfs;path=UNC\192.168.2.202\EX2Ult;uid=1000;gid=1000;symlinkroot=/mnt/) failed: Invalid argument

======================================

On XPS8950:

uname -a

Linux XPS8950 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

This works:

 sudo mount -t drvfs -o rw,noatime,uid=1000,gid=1000 '\\192.168.2.202\\EX2Ult' /mnt/ex2ult

This fails:

 sudo mount -t cifs -o guest,uid=1000,iocharset=utf8 //192.168.2.202/EX2Ult /mnt/ex2ult

The error response is:

mount: /mnt/ex2ult: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount. helper program.

===================================================

The following addition is in response to a question by @geary, but it is too complex to put as an answer.

I figured the question was already complicated enough without adding in a history. So first I'll answer the "what if..." part.

For a starting point, on the older system that has been working with. To summarize the details below, this is the only command that works. It needs the -t drvfs:

sudo mount -t drvfs -o rw,noatime,uid=1000,gid=1000 '\\192.168.2.202\\EX2Ult' /mnt/ex2ult

if I remove -t, or use -t auto, I get:

mount: /mnt/ex2ult: special device \\192.168.2.202\\EX2Ult does not exist.

Removing the rest of the options has the same result.

Using the other format, the response is always:

mount: /mnt/ex2ult: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program.

By the "other format", I mean:

sudo  mount -t cifs -o guest,uid=1000,iocharset=utf8 //192.168.2.202/EX2Ult /mnt/ex2ult

It is the same response with -t auto or eliminate -t or eliminate all of the other options, the

FYI, the "other format" has been in use on a straight Ubuntu system for a long time. I think I came up with it in version 14.04 or 16.04. That's why there is a "guest" account. The -t drvfs was used starting with WSL when the format I had been using didn't work.

The latest system (the one with the updated kernel) can't handle the -t drvfs at all. So I have one (two actually, there's also a Win 10 system) systems that need -t drvfs and one that won't connect if it's used.

Answer 1

First off, welcome to AskUbuntu! We're glad that you came to us with your question.

I did a little research into the Mount command and found this post. It mentions specifically that you shouldn't have to specify the FS. So, what happens when you don't specify or use auto, instead?

Also, I notice that on one you specify a guest account and the other you don't. Is there a reason for this change?

[Edit] @OPunWide: So a little more digging and I found out that cifs and drvfs are both systems that allow you to mount Network drives. It's possible that cifs isn't installed. Verify that both are on both machines, then run your test again. You should be able to do this with: sudo apt install cifs-utils

According to Microsoft, DrvFs is a filesystem plugin to WSL that was designed to support interop between WSL and the Windows filesystem,so there may be some oddities in how these systems interact with different Windows versions.

Another option is include some error handling in your python script that tries cifs first, then tries drvfs when that doesn't work, then sets a variable so that it sticks with the one that works(Until an M$ update breaks it, anyway).

Answer 2

I'm giving up on my original goal of understanding the problem. I found a solution that allows me to move on from this, but it involved changing the older systems.

Thanks to @Geary for the reminder on cifs.

All of the systems work if "cifs-utils" is installed. I may have done that early in the process on the new computer and that's why it was working, but ¯\_(ツ)_/¯

To stick with the original example, this works on all systems once "cifs-utils" is installed:

 sudo mount -t auto -o guest,uid=1000,iocharset=utf8 //192.168.2.202/EX2Ult /mnt/ex2ult

I'm fairly well convinced that it's something in the Linux core that happened between 5.10.16.3 and 5.15.0-69. The 5.15 version of the mount command does not seem to support the type that I had been using "-t drvfs".

If anybody knows when the change happened or how to detect it, other that having the failed mount command, I'd appreciate a post to explain it.