Mount Google Drive File System to WSL

[rjh336]

@bitcrazed I plan to follow your recommended instructions to backup /home/<user> and installed packages from #2955.

However, I would like to compress the backup in a tar.gz archive per these instructions, and I would like to store that archive in my Google Drive File System (GDFS). My GDFS is located in my windows file system in the G: drive. However, when I try to view this drive, I am met with the following:

rjh336@LAPTOP-ETTS75F8:/mnt/g$ ls /mnt
c  d  g
rjh336@LAPTOP-ETTS75F8:/mnt/g$ cd /mnt/g
rjh336@LAPTOP-ETTS75F8:/mnt/g$ ls -la
ls: reading directory '.': Function not implemented
total 0

Upon trying to save an archive in that location, I see a similar error message:

rjh336@LAPTOP-ETTS75F8:~$ tar -cvpzf /mnt/g/backup.tar.gz --exclude=./test_src/exclude_folder ./test_src/
tar (child): /mnt/g/backup.tar.gz: Cannot open: Function not implemented
tar (child): Error is not recoverable: exiting now
./test_src/
./test_src/.folder_hidden/
./test_src/.folder_hidden/.hid_file
./test_src/.hidden
./test_src/file.txt
./test_src/folder_visible/

Is there a proper way to mount the Google File System from windows? Or perhaps a way to mount this drive directly on WSL? I checked the File system on G: and it says it is "FAT32". Any advice is greatly appreciated!

[therealkenc]

Variation on #2896 (VirtualBox additions shared folder) #2163 (WebDAV) #1962 (Windows NFS and/or Dokany) #579 (EXT2FSD). WSL DrvFS can only grok certain Windows filesystems presently.

[deven]

I currently have Windows 10 build 16299. I installed Google Drive File Stream, and my Google Drive is visible as I: under Windows. When I launch a WSL bash shell, this is getting automatically mounted as "/mnt/i". While I also get the "Function not implemented" error, I have found that I can nevertheless change into subdirectories and read/write files via DrvFS to Google Drive, I can even do "ls -l" on a specific file without getting any errors.

I just can't read directory entries, which obviously makes the filesystem a little difficult to use!

Running strace shows that getdents() is the system call which is failing:

openat(AT_FDCWD, ".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, 0x21f6890, 32768) = -1 ENOSYS (Function not implemented)

If just this syscall could be fixed for the Google Drive File Stream filesystem, it might work perfectly.

[taylorpaul]

I am encountering the same issue!

[YenForYang]

This issue is probably also similar to "ls: reading directory '.': Invalid argument (share mounted via drvfs) #1954"

For me:

richard@Richard-Works:/mnt$ ls
ls: cannot access 'g': Invalid argument
c  d  g  z
--------------------------
richard@Richard-Works:/mnt$ cd /mnt/g
--------------------------
richard@Richard-Works:/mnt/g$ ls
ls: cannot open directory '.': Invalid argument
--------------------------
richard@Richard-Works:/mnt/g$ cd ..
--------------------------
richard@Richard-Works:/mnt$ sudo mount -t drvfs G: /mnt/g
--------------------------
richard@Richard-Works:/mnt$ cd g
--------------------------
richard@Richard-Works:/mnt/g$ ls
ls: reading directory '.': Function not implemented

Quoting @SvenGroot from that issue,

All of these issues are caused by file systems that either do not support some of the functionality DrvFs is trying to use, or behave in unexpected ways. Officially, DrvFs currently support NTFS, ReFS, FAT, CDFS, and SMB.

Which is unfortunate, as the list doesn't include FAT32, though this was in June last year.

[SvenGroot]

@YenForYang By FAT I meant the FAT driver in Windows. WSL definitely works with FAT32, and all the FAT variations Windows supports.

I do expect this is another case where the Google Drive file system driver is missing some support or behaving in an unexpected way.

[jvallery]

Any update on this? This would be killer if I could work with the files on my G Drive via WSL.

[bastiao]

This will be really nice to have!

[h3xcat]

I found that if you share the drive over the network, you can mount the share from different computer and run commands within drive folders without problems. But I was unable to mount it using localhost, it knows that you're trying to mount the local drive and just mounts it as regular drive.

Edit:
I believe it's not working on localhost due to named pipes, and I don't think it's something you're normally able to disable without breaking all bunch of other things

[chris2crawford]

Here is a way to mount GFS in WSL based on https://superuser.com/questions/1353169/getting-sshfs-working-on-wsl-or-finding-an-alternative The trick is to use https://www.nsoftware.com/sftp/netdrive/ to ssh to GFS from Windows and convert it to a filesystem that can be mounted under WSL.

1. Install OpenSSH Server under Win10
   Win10 Settings -> Apps -> Manage optional features -> Add feature -> OpenSSH Server
   restart if necessary
   open Services -> OpenSSH -> Properties -> Startup Type -> Automatic (delayed)
2. Install and run SFTPNetDrive, right click on icon in hidden icons -> Main window (or maybe already open) -> Profile -> new profile ( server: localhost, user: *** pwd:*** Drive Letter: F (or another)
   Advanced -> ( Protocol -> uncheck compression; Specified folder: G:\ ) )
3. in Bash (wsl): sudo mkdir /mnt/f; sudo mount -t drvfs F: /mnt/f
   I'm not sure how stable it is, but I was able to open files in WSL.

[h3xcat]

I switched to RaiDrive, haven't gotten any problems yet. And upload speeds are way better than using Google File Stream.

[chris2crawford]

from: Riyad Muradov

1. Install RaiDrive, map your GDrive to a network drive.
2. In the explorer, go to Network, you should find the network location named RaiDrive-username.
3. In Bash, create a new directory and mount the network location:
   $ sudo mkdir /mnt/mydrive
   $ sudo mount -t drvfs '\RaiDrive-username' /mnt/mydrive

I agree the performance is much better than SFTPNetDrive. I got the following error on the last command:

mount: /mnt/mydrive: wrong fs type, bad option, bad superblock on \RaiDrive-crawf, missing codepage or helper program, or other error

However, just using the windows drive worked fine:
$ sudo mount -t drvfs Z: /mnt/mydrive

[katherinelauck]

Just fixed the same exact thing on my own Win10/WSL Ubuntu with @chris2crawford 's solution. I would prefer to access GFS directly because of its ability to cache files. Has anyone feature requested this to GFS?

[dos-gruut]

Hi guys, I have a simple way to do this, even this way is not actually to mount the drive. But basically, you can read or write on it.

I just wanted to copy a file from WSL into the Google Drive file stream. (For example, G: \ My drive \ hobby)
So, I wrote a copy-to-drive.sh which contains just one line code below.

cmd.exe --% /c copy 'C:\Users\dos\workspace\hobby\sample.txt' 'g:\My Drive\hobby'

Yes, you can invoke the windows cmd on the WSL.
I hope this can help you guys.

[therealkenc]

Yes, you can invoke the windows cmd on the WSL.

With recent WSL you should be able to go the other direction too under powershell with something like:

$ powershell.exe -Command "copy C:\\some\\path\\to\\file \\\\wsl$\\Ubuntu-18.04\\some\\directory"

Another (similar in spirit) way to go would be set up ssh.exe on Windows and use scp.exe, or even go the other direction and set a sshd server on Windows. Whatever it takes so long as the file is being read/written on the Windows side and not going through WSL drvfs.

It is also possible to use some nested IFS ideas as suggested earlier. Nothing wrong with that in principle, but going that way is stacking one (at least potential) path to failure upon another. If it "works" so much the better, but just be aware there are a lot of unknown/untested/unsupported moving parts involved going that route. Going through interop is at least in theory a solution that should work by design.

[Masterxilo]

I came here because of this very disappointing answer: https://askubuntu.com/questions/1094020/how-can-i-access-my-google-drive-or-external-hard-from-windows-bash

[steinbergnet]

This issue is now more than 1.5 years old.
Any updates here? Will Microsoft do anything about this?
It should not be soo hard to make 9P work with network drives.

Practically this is a complete showstopper for me to use WSL (1 or 2).
ALL my important files live inside GDFS. Without access to GDFS
WSL is next to useless.

I tried using RaiDrive but the performance was much too slow for any real work.

Sharing GDFS via SMB also did not work.

Did anyone find a working solution?

[bitcrazed]

@steinbergnet and @Masterxilo - As per @SvenGroot's response above, this issue is likely caused by GDrive misbehaving. You might want to file an issue on Google.

I advise this reluctantly - I hate it too when vendors seem to point fingers - but WSL just treats drives as ... well ... drives. If the drive behaves, one can access the drive from WSL:

And I don't want to sound biased, but if GDrive isn't able/willing to make this change, you might perhaps have to consider other cloud file sync providers.

[steinbergnet]

From what I see it looks like you are accessing a local directory on your C: drive that might be mirrored to OneDrive, but not OneDrive itself. I tried accessing my OneDrive (mounted as separate drive) and it failed the same way as GDFS.

…

On Fri, Oct 18, 2019 at 6:25 PM Rich Turner ***@***.***> wrote: @steinbergnet <https://github.com/steinbergnet> and @Masterxilo <https://github.com/Masterxilo> - As per @SvenGroot's response above <#2999 (comment)>, this issue is likely caused by GDrive misbehaving. You might want to file an issue on Google. I advise this reluctantly - I hate it too when vendors seem to point fingers - but WSL just treats drives as ... well ... drives. If the drive behaves, one can access the drive from WSL: [image: image] <https://user-images.githubusercontent.com/961950/67110973-ce453880-f188-11e9-93ae-f384d5277244.png> And I don't want to sound biased, but if GDrive isn't able/willing to make this change, you might perhaps have to consider other cloud file sync providers. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2999?email_source=notifications&email_token=AF3TABGHZVGT773POV5MSDTQPHPN3A5CNFSM4ET4PJ2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBVAVSA#issuecomment-543820488>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF3TABBGEY7D2KOF6H6RL33QPHPN3ANCNFSM4ET4PJ2A> .

[therealkenc]

If the drive behaves, one can access the drive from WSL:

That's "not wrong". These third-party IFS problems can be solved on the Windows driver side. Here's hoping that happens. There is a credible counter line of reasoning though. The IFS isn't misbehaving on Windows, and working on Windows is a pretty good definition of working.

In the case of Google Drive, a constructive path forward would be to try to convince them to officially support Linux. Or for someone highly motivated to do it for them. If one took this and this one could probably get there with effort.

Sharing GDFS via SMB also did not work.

Made me look. Works here. Leads credibility to thesis it ought work on 9p, becuase same thing modulo implementation detail.

[judge2020]

@therealkenc That's the wrong Google Drive system. Drive FIle Stream is for GSuite accounts and opening files pulls from the server on-demand, instead of downloading everything and syncing.

https://www.google.com/drive/download/

[wsl 1]

[therealkenc]

Drive FIle Stream is for GSuite accounts

Ah. Don't have one of those. So you're faced with the double whammy of no one without a GSuite account able to repro let alone suggest a fix. Most unfortunate.

[edit] You're still showing the 9p fail, not the mount -t cifs fail with a Drive File Stream folder shared. If you can't share it on Windows (wouldn't know, don't have GSuite) then all bets are off and that's a "talk to Google" thing. If you can share a Drive File Stream folder but can't mount it in WSL2 that would be curious.

[Rondom]

Given that GSuite is a paid for product, I think it does not do any harm to open a support ticket with them.

[steinbergnet]

Let's be realistic. Google Drive is not misbehaving. It works as designed as a drive under Windows. The fact that WSL2 somehow does not handle it correctly can hardly be considered a bug, especially since WSL2 is still in development. Clearly the problem lies somewhere in the WSL2/9P code. Since Microsoft is propagating WSL it should have a look at this issue.

…

On Sat, Oct 26, 2019 at 11:17 PM Andreas Gnau ***@***.***> wrote: Given that GSuite is a paid for product, I think it does not do any harm to open a support ticket with them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2999?email_source=notifications&email_token=AF3TABFMHJ7LWPLZVGMWZ5LQQSXXHA5CNFSM4ET4PJ2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECKRCVA#issuecomment-546640212>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF3TABF2R5727WQDY3BWIALQQSXXHANCNFSM4ET4PJ2A> .

[SvenGroot]

WSL as a file system client is a bit more strict about how a file system needs to behave than Windows in general. This goes both for WSL 1 and WSL 2, because while the mechanism of actually getting to the files is quite different, the actual code that interacts with the file system is mostly the same. For example, we require file systems to support one of a few directory information classes that we use to enumerate directories. Windows has more information classes than the ones that WSL supports, but they don't provide the information WSL requires.

DrvFs is the component of WSL that interacts with native Windows file systems. In this context, that also refers to the 9p server used to access Windows files on WSL 2. DrvFs was originally designed to access only NTFS. We've long since updated it to support the various flavors of FAT supported by Windows, CDFS, and SMB (with the main target being a Windows SMB server sharing an NTFS volume). Everything that works besides that is pretty much just lucky, not officially supported.

I would definitely not mind taking a look at GDrive to see what we do that mystifies it, and if it's something we can work around, but that's pretty much only possible if I can get it under a debugger. To do that, I need access to a machine from someone who as an account, since it's a paid service so I don't have one.

[chris2crawford]

Dear Sven, I really appreciate you taking a look. I have had some success with RaiDrive, but its performance lags behind GFS, and occasionally I get the blue screen, for example, when starting up emacs from the shared drive. Email me at crawford@pa.uky.edu to arrange for remote access to my account. --Chris

…

On Tue, Oct 29, 2019, 18:27 Sven Groot ***@***.***> wrote: WSL as a file system client is a bit more strict about how a file system needs to behave than Windows in general. This goes both for WSL 1 and WSL 2, because while the mechanism of actually getting to the files is quite different, the actual code that interacts with the file system is mostly the same. For example, we require file systems to support one of a few directory information classes that we use to enumerate directories. Windows has more information classes than the ones that WSL supports, but they don't provide the information WSL requires. DrvFs is the component of WSL that interacts with native Windows file systems. In this context, that also refers to the 9p server used to access Windows files on WSL 2. DrvFs was originally designed to access only NTFS. We've long since updated it to support the various flavors of FAT supported by Windows, CDFS, and SMB (with the main target being a Windows SMB server sharing an NTFS volume). Everything that works besides that is pretty much just lucky, not officially supported. I would definitely not mind taking a look at GDrive to see what we do that mystifies it, and if it's something we can work around, but that's pretty much only possible if I can get it under a debugger. To do that, I need access to a machine from someone who as an account, since it's a paid service so I don't have one. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2999?email_source=notifications&email_token=ACYGBEVHHX3REKV3AYO6NYLQRC2GTA5CNFSM4ET4PJ2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECSJJXY#issuecomment-547656927>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYGBEX4RFJCAODHGNWZEVLQRC2GTANCNFSM4ET4PJ2A> .

[therealkenc]

Thanks for the details Sven; your write-ups are always appreciated.

Windows has more information classes than the ones that WSL supports, but they don't provide the information WSL requires.

I have been half-meaning to ask for some time (but didn't) whether it is possible/practical to loosen our definition of "requires" for a few (probably common) pain points. For example I took a run once at getting Dockany mounted on WSL. Didn't work; they don't implement FILE_STANDARD_LINK_INFORMATION. I didn't bother you with it at the time; not your problem. It is fixable in Dockany for someone motivated, totally.

But this said, can we reasonably or realistically survive without (in this arbitrary example) NumberOfAccessibleLinks? If we fail to get FILE_STANDARD_LINK_INFORMATION, fall back to less esoteric FILE_STANDARD_INFORMATION, which you gotta know the filesystem implements, or they'd fall down on Windows. If WSL "requires" the schmancy NumberOfAccessibleLinks (to track deleted links), punt on hard links altogether. Hard links are not well supported on some FUSE filesystems anyway; for example, the canonically popular sshfs. So in the case of missing required info (and again we're just using Dockany as an illustrative example here) say: "no hardlinks for you". link(2) fails by-design and stat.st_nlink for files is 1. [I bet a nickle GDrive doesn't support NTFS hard links either, even if that is almost certainly not the blocker here.]

we require file systems to support one of a few directory information classes that we use to enumerate directories

Understood. You don't say which ones, but, similar to the link information example, nothing too schmancy (high _FILE_INFORMATION_CLASS identifier) can near by definition be a hard requirement of WSL, for the fact that you've been able to SMB2 mount a Windows share on Real Linux for decades, before all the esoteric info classes were invented. Which is why I asked the (still pending) follow up regarding (quoth) "Sharing GDFS via SMB also did not work". If GDrive doesn't support enough *INFORMATION classes to SMB share a directory, that would be (a) a little surprising, and (b) plainly a limitation of that filesystem. [I'm at a disadvantage to either confirm or deny said limitation without GDrive.]

[pdkovacs]

And today it seems to work again (with no updates applied):

pkovacs@/mnt/c/Windows/system32 $ ls /mnt/g/
'$RECYCLE.BIN'  'My Drive'  'Shared drives'

[Dr-Irv]

Here is a workaround that provides some minimal shell capabilities for GDrive. I needed to inspect a file on Google Drive Stream using tail, and found that using the bash supplied with Git on windows allowed me to do that. My Google Drive is G: in DOS:

 G:\>"c:\Program Files\Git\bin\bash

<REDACTED> MINGW64 /g
$ ls
'$RECYCLE.BIN'  'My Drive'  'Shared drives'

<REDACTED> MINGW64 /g
$ ls My\ Drive/*.JPG
'My Drive/IMG_2039.JPG'  'My Drive/IMG_2040.JPG'  'My Drive/IMG_2041.JPG'

[nelsonjchen]

Not sure if this matters for anyone but "Google Drive for desktop" seems to work well for my gmail Google account. Drive File Stream did not work in the past. This seems to be a new successor to Drive File Stream that works for all Google accounts.

https://support.google.com/a/answer/7491144/deploy-google-drive-for-desktop?utm_medium=et&utm_source=aboutdrive&utm_content=getstarted&utm_campaign=en_us&hl=en

https://support.google.com/googleone/answer/10309431/upcoming-changes-to-google-drive-sync-clients?hl=en#zippy=%2Cwill-anything-happen-to-my-files-when-drive-for-desktop-releases%2Cwhy-are-you-making-this-change

In other words, a G Suite account is no longer required to test this functionality.

I have tested the current WSL version that's required for WSLg with "Google Drive for desktop" and it works! 😄

[traversjames]

So it looks like "Google Drive for desktop" access now works for WSL2 but USB/serial ports don't. Accessing these hardware resources works on WSL1 but "Google Drive for desktop" doesn't. I need both 😩.

Since I looked at this issue last, however, it seems Google have re-enabled "Backup and Sync" - they seem to flip-flop a lot on their drive offerings. This means that the synced files are directly accessible on WSL1 with hardware port access. "Google Drive for Desktop" can be run in parallel - maybe this was obvious but this now covers all use cases for me.

[pesobreiro]

Hello everyone, following the idea of @nelsonjchen and @traversjames, if this still matters. But this is truly annoying when using google drive. I think the simple approach is to install [backup and sync](https://www.google.com/drive/download/ basically the same thing with few functionalities. Google drive download per use vs the files being available locally in backup and sync, which allows to access them using the mount of the windows drive in wsl.

[Liryna]

WSL 1 compatibility was fixed in the latest Dokan release. Google Drive will ship this version in a coming version.

[adamsd5]

I upgraded to Google Drive for Desktop yesterday. I cannot access /mnt/g/.
ls: cannot access '/mnt/g': Invalid argument

Using WSL2 and Ubuntu 20.04LTS

[sglaser]

The initial issue works for me (did nothing special, someone must have fixed things).

Unfortunately, there's another minor issue now:

For all files seen from my Google Drive (paid version), Ubuntu under WSL sees Inode #2. This causes find(1) to complain about file system loops that aren't real. For example:

$ find . -print
find: File system loop detected; ‘./Base-6.0’ is part of the same file system loop as ‘.’.
...

$ ls -l -d -i . ./Base-6.0
2 drwxr-xr-x 0 sglaser sglaser 512 Jul 22 15:33 ./
2 drwxr-xr-x 0 sglaser sglaser 512 Jun 29 10:43 ./Base-6.0/
...

[Liryna]

@sglaser this is an known issue and will be fixed after the version 50 will be fully deployed.

[Liryna]

Google Drive version 50 is released and should cover all issues mentioned here.
@therealkenc I believe this can now be closed.

[madzafv]

Trying to mount my gdrive on WSL2 using rclone and getting this.

sudo rclone mount gdrivebrown ../../mnt/d
2021/09/04 21:04:03 mount helper error: fusermount: fuse device not found, try 'modprobe fuse' first
2021/09/04 21:04:03 Fatal error: failed to mount FUSE fs: fusermount: exit status 1

modprobe fuse
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-19041-Microsoft/modules.dep.bin'
modprobe: FATAL: Module fuse not found in directory /lib/modules/4.4.0-19041-Microsoft

sudo apt install fuse
Reading package lists... Done
Building dependency tree
Reading state information... Done
fuse is already the newest version (2.9.4-1ubuntu3.1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up friendly-recovery (0.2.31ubuntu2.1) ...
/usr/sbin/grub-probe: error: failed to get canonical path of `rootfs'.
dpkg: error processing package friendly-recovery (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

Appreciate any help on the issue.

[ghost]

@madzayasodara I don't think you can mount with your WSL2-distro rclone package. You'd need to mount with the rclone.exe in Windows and then should be able to access it inside your WSL2 distro.

[madzafv]

I also have my gdrive mounted as a network drive, which I have mounted using mountain duck, but cannot access it from my WSL2.... Then when I mount it in WSL, a weird never-ending mirrowing happens.

sudo mount -t drvfs D: /mnt/d
$ ls /mnt
c  d  e  f  g
$ ls /mnt/d
My Drive  Shared Drives  Shared with me
$ ls /mnt/d/My\ Drive/
My Drive  Shared Drives  Shared with me
$ ls /mnt/d/My\ Drive/My\ Drive/
My Drive  Shared Drives  Shared with me

[madzafv]

Ok I mounted gdrive as a drive using the new Google Drive and then mounted in WSL2
sudo mount -t drvfs D: /mnt/d
seem to be working now

[vinhdizzo]

@Liryna I just migrated to Google Drive version 51.0.9.0 on Windows 10. I am on WSL 2. G drive shows up on /mnt/g in bash, but I still get the error:

/mnt/g$ ls -lrtha
ls: reading directory '.': Invalid argument
total 0

I can navigate to the drive with no problem:

/mnt/g$ ls -lrtha
ls: reading directory '.': Invalid argument
total 0

Am I doing something wrong? Thanks!

[Liryna]

@vinhdizzo could you share the exact command line you used to mount the drive ?

[vinhdizzo]

@Liryna when I launch bash, the G drive is already mounted as /mnt/g, so I didn't need to mount. I could unmount and remount, and I get the following:

$ sudo umount /mnt/g
$ sudo umount g
$ cd /mnt/g
$ ls -lrtha
ls: reading directory '.': Invalid argument
total 0

[Liryna]

@vinhdizzo what happens if you try to mount by using the same commande line in other answers?

[vinhdizzo]

@Liryna Here's what I get:

$ sudo mount -t drvfs '\\localhost\G' /mnt/g
mount: /mnt/g: special device \\localhost\G does not exist.
$ sudo mount -t drvfs '\\192.168.1.123\G' /mnt/g
mount: /mnt/g: special device \\192.168.1.123\G does not exist.
$ sudo mount -t drvfs '\\192.168.1.123\G$' /mnt/g
mount: /mnt/g: special device \\192.168.1.123\G$ does not exist.

C drive is OK:

sudo mount -t drvfs '\\192.168.1.123\c' /mnt/g

That was the only command I saw in the thread that is based on Google Drive and not other third party tools. Did you want me to try anything else? Thanks!

[Liryna]

@vinhdizzo please give a try to:
sudo mount -t drvfs G: /mnt/g

[vinhdizzo]

@Liryna sorry I did try that first but forgot to paste it. This is what I get:

$ sudo mount -t drvfs G: /mnt/g
$ cd /mnt/g
$ ls
ls: reading directory '.': Invalid argument

[sudeshjethoe]

this works for me, but sometimes it helps to unmount first, e.g. umount /mnt/g (as root ofcourse)

[pgwilliams]

I've no idea when this started working (it wasn't the last time I checked - perhaps 6 months ago) but today it's working fine. Within my WSL Ubuntu I navigated to /mnt/ and there was my G drive (mapped as G:), and from there I went to /mnt/g/My Drive/ and all my files were there as expected. Happy Customer 😄 👍

[ilsaloving]

This only works for your personal documents. If you want to use a Shared Drive, it is completely inaccessible. In fact, it is unusable from anything other than explorer. I tried several different tools in addition to WSL, and they all either displayed nothing, or just a .lnk to some inaccessible location.

[chris2crawford]

I use WSL plus shared drives using Google Drive for Desktop. But it only works for shared drives in my own organization, not shared from other companies. Not sure why.

[mujina93]

Just want to signal: I updated WSL from v1 to v2. Before, when I fired up the Google Drive app, I found G: automatically mounted at /mnt/g (this allowed me for example to right click > open windows terminal with wsl in any folder within G:).

Now, with WSL2, it doesn't work anymore.

Mounting manually with sudo mount -t drvfs G: /mnt/g works, but downgrading from "it works out of the box" to having to having to do things manually is a bit annoying.

[steinbergnet]

Hello, I always start Windows Explorer from WSL2/bash using the mounted Google Drive file system. Since the last WSL Update this week I started to get this error message after running WSL for a few hours when I run explorer from bash: $ explorer.exe G: <3>WSL (2209) ERROR: UtilBindVsockAnyPort:295: bind failed 38 Rebooting will fix the issue, but it will reappear after a few hours. Any ideas how to fix this? Is there a way to downgrade WSL to the previous version?

[literakl]

I have used Debian to search files on G drive successfully but suddenly it stopped working. Tried Google drive restart without luck:

literakl@DESKTOP-590U5T0:/$ ls -l /mnt/
ls: cannot access '/mnt/g': Invalid argument
ls: cannot access '/mnt/l': Invalid argument
total 0
drwxrwxrwx 1 literakl literakl 512 Jan 14 09:11 c
d????????? ? ? ? ? ? g

Edice Windows 10 Home
Verze 22H2
Datum instalace ‎30.‎11.‎2022
Build operačního systému 19045.2486
Výkon Windows Feature Experience Pack 120.2212.4190.0

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!