Where Drive for Desktop runs out of road
Google's client is genuinely good at the job it was built for. It keeps a Drive folder present on your machine, it understands Google's own document types, it handles conflicts. If that is your whole workflow, there is no reason to change anything.
Three gaps push people to look elsewhere.
First, there is no Linux build. Not a limited one, not a community edition Google maintains. None.
Second, the mount behaviour is a setting you pick once, stream or mirror, and the answer that suits a laptop's 256 GB SSD is rarely the answer that suits an archive folder.
Third, every extra Google account arrives as its own mount point with its own state. That gets tedious the moment you are running a work account, a personal account and a client's shared account at once.
Mount Google Drive as a network drive through a local WebDAV endpoint
Different shape of solution: instead of a filesystem driver, run a small WebDAV server on your own machine and let the operating system mount that. AnyStorage does this. No kernel extension, no macFUSE, no WinFsp, no admin password, no config file to edit.
The path from nothing to a mounted drive:
- Add a Google Drive connection in AnyStorage and complete the OAuth sign-in inside the app.
- Open the connection once so it is live.
- In the sidebar, go to Services and switch to the WebDAV tab, then press Start. The address is http://127.0.0.1:3211 by default; the port is editable if 3211 is taken.
- Copy the username and password from the same panel. Username is anystorage unless you change it, and the password is 24 random characters generated on first use. Basic auth is always on and cannot be disabled.
- On macOS, open Finder, choose Go, then Connect to Server (Cmd+K), paste the URL and authenticate as a registered user.
- On Windows, open File Explorer, right-click This PC, choose Map network drive and paste the same URL.
Windows deserves a warning rather than a footnote. As of 2026 the native WebClient service is deprecated and usually not running, so start it from services.msc before you map anything. It also refuses HTTP Basic authentication by default: set BasicAuthLevel to 2 under HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters and restart the service, otherwise you get "The folder you entered does not appear to be valid" or System error 67. And FileSizeLimitInBytes defaults to 50,000,000 bytes, so a 90 MB video fails with 0x800700DF until you raise it, up to a hard ceiling of 4294967295. Any third-party WebDAV client avoids all three, and so does moving the file inside AnyStorage itself.
Three accounts, one drive
Connect each Google account as its own connection. Each one shows up as a folder at the WebDAV root, named after the connection. One mounted network drive, three Drive accounts inside it, sitting next to whatever else you have connected — S3 buckets, an SFTP host, Dropbox, a plain local folder. Twenty connection types can appear there.
One caveat we would rather state than hide: after restarting the app, a connection only appears under the WebDAV root once you have opened it in the app, because connections connect lazily. Connections you add later show up without restarting the server.
Or skip the mount: Drive as one connection among many
Mounting is optional. The app itself works as a Google Drive desktop client: Drive folders open in tabs beside an S3 bucket, a local project folder and an SFTP host, and files move between them through the transfer view with progress and history instead of a download-then-upload round trip. For projects where the deliverables live in Drive and the renders live in a bucket, that is one window rather than a browser tab plus two other tools. OAuth tokens and credentials stay encrypted on the machine, and the free tier covers two connections with commercial use allowed.
The Linux answer
This is the case where the gap is absolute. AnyStorage ships for Ubuntu 20.04 and later as an AppImage or a .deb, and the WebDAV route works exactly as it does elsewhere. Start the server, then connect from your file manager: GNOME Files takes dav://127.0.0.1:3211 under Other Locations, Dolphin takes webdav://127.0.0.1:3211, and both will ask for the same username and password. Reads stream with HTTP range support, so scrubbing through a video in mpv does not download the file first.
What this is not
It is not offline sync. Nothing is pre-fetched; files stream on demand. On a plane, a mounted drive is an empty promise, and a real sync client or a plain download is the correct tool.
The Google-native document formats are not ordinary files inside Drive, so keep editing those in the browser.
On the free tier the WebDAV server is read-only. You can browse, open, stream and copy files out; writing back needs a Pro license and the Full control setting. Read-only is also worth choosing deliberately on Pro when the mount points at a shared work Drive.
Two connection folders are not a copy path. Dragging a file straight from the Google Drive folder into the S3 folder inside the mount does not work, and the top-level connection folders cannot be renamed or deleted over WebDAV. Cross-storage moves belong in the app's transfer view, or go through a local folder first.
There is no TLS. The URL is plain http and the credentials are HTTP Basic, which is why we bind to 127.0.0.1 by default. A LAN mode exists that binds 0.0.0.0, and the app puts a warning next to it because those credentials would then cross the network in clear text. There is also no file locking, so two machines editing the same document are on their own.
Nothing here needs a reboot, a signed driver or a reduced-security boot on Apple Silicon. If it does not suit you, stop the server and the mount is gone.