The Google Drive folder on a Mac: where the files really live

The Google Drive entry in the Finder sidebar looks like a folder, opens like a folder, and is not in any of the places a folder would be. It does not appear in the home directory. Spotlight behaves oddly around it. A script that worked against it last year now fails with a path that no longer exists. And the settings that used to move it somewhere sensible are documented as no longer applying.

None of that is a fault. It is the consequence of one architectural change, and knowing what that change was makes the rest of the behaviour predictable instead of mysterious.

The sidebar entry is not a folder in the ordinary sense

Google's own description of what installation does is straightforward: installing Drive for desktop creates a drive in My Computer on Windows, or a location in Finder named Google Drive on a Mac, and all Drive files appear there. The word "location" is doing real work in that sentence.

On current versions of macOS, that location is provided by File Provider, the system mechanism through which cloud storage services present their contents to the Finder and to applications. Google states the consequence plainly in its advanced Drive for desktop configuration reference. The DefaultMountPoint setting, which on a Mac set the mounted drive path and accepted a tilde or environment variables, carries the note that it does not apply to macOS version 12.1 and later, because for those versions Drive for desktop uses File Provider and macOS controls the mount point.

That single sentence explains most of the surprises. The location is not chosen by Google and cannot be chosen by the person using it. It is chosen by macOS, in a place macOS reserves for the purpose.

The same note appears twice more in the same reference, attached to the caching settings, which is worth knowing before anyone goes looking for a cache to clear. ContentCachePath documents a default of ~/Library/Application Support/Google/DriveFS and then states that the setting does not apply to macOS 12.1 and later, where macOS controls the location of cached data. ContentCacheMaxKbytes, which caps the cache in kilobytes and is itself limited to 20 percent of available disk space, carries the same exclusion, with macOS controlling the size of the cache instead.

Where the real path is

macOS collects File Provider based cloud storage under ~/Library/CloudStorage, with one entry per service and account. Opening that folder on a Mac with any such service installed shows the pattern immediately: a directory named after the provider, and for Drive, with the signed-in address attached, because several accounts can be connected at once.

The reliable way to get the exact string is to ask rather than to guess. Open the folder in the Finder, drag it onto a terminal window, and the full path is pasted. Alternatively, with the folder open, a terminal sitting in it reports the path with pwd. Both take a few seconds and neither depends on remembering a naming convention that has changed before.

Google supplies a shortcut to the folder itself. The Drive for desktop menu, which on a Mac sits at the top right in the menu bar, has an Open Drive folder item, and Google's instructions point at it as the normal way in.

Two properties of that path matter for anything scripted. It contains spaces, which means it needs quoting in a shell, and it contains an at sign as part of the account name, which trips up tools that try to interpret the string as a remote host. Assigning it to a variable once, quoted, and using the variable afterwards avoids both.

The number of accounts is capped. Google states that up to four accounts can be used at one time with Drive for desktop, so there is a ceiling on how many of these locations can exist side by side.

Streaming and mirroring are not two views of the same thing

The other half of the confusion is about what is on the disk at all, and Google's own wording is the clearest available. Streaming a file uses almost no computer space, while mirroring downloads a full copy directly to the computer.

This is the difference between a name that stands in for a file and the file itself. A streamed folder can list thousands of items while occupying almost nothing, and each one materialises when something opens it. A mirrored folder holds real bytes.

Google attaches a caution to the same page that catches people out in both directions. The space tracker inside Drive for desktop shows the room left on the computer's hard drive, not the Google Account storage, and those two numbers are unrelated. Shared files can fill up a hard drive if they are synced, and they never count against Google storage.

The practical consequence is worth stating directly. A disk that filled up after joining a shared drive has not consumed any cloud quota, and freeing cloud quota will not give the disk its space back. They are two separate problems that happen to be reported in the same window.

Why a search finds things a shell does not

Search behaves differently here, and Google says why. The search inside Drive for desktop finds all files from the streamed Google Drive location, and Google's documentation states that this is unlike Windows Search or macOS Spotlight. The default hotkey on a Mac is documented as the Command key with the accent key and g, and it can be reassigned in advanced settings.

The reason it needs its own search is the same architecture as before. Contents that have not been materialised are not sitting on the disk to be indexed in the usual way, so a tool that walks the filesystem sees names without bodies.

This has consequences for anything run from a shell. A recursive grep across a streamed folder is asking for every file to be fetched, which is slow and generates a lot of traffic. A find by name is cheap because names are present. A du on the folder reports what has been materialised locally rather than what the account holds, and reading it as a measure of the account's usage produces the wrong answer.

There is a second class of file to keep in mind. Google states that files created by Google Docs, Sheets, Slides or Forms open in a browser, while other files open in their regular applications. Anything that walks the folder expecting editable documents will not find them for that group, because for those items the editable version lives in the browser.

When the folder is missing entirely

A sidebar entry that is not there at all is a different problem from one that is in an unexpected place, and it has a short list of causes.

The first is that the application is not running. Google's instructions treat the menu bar item as the way in, and on a Mac that item sits at the top right. No menu bar item means nothing is running, and nothing running means no location for the Finder to show. The AutoStartOnLogin setting in Google's advanced reference is a boolean that starts Drive for desktop at session login, which is the durable fix for a Mac where it keeps having to be launched by hand.

The second is that nobody is signed in. Google notes that on first launch, or after an account has been disconnected, signing in happens through Get started and then Sign in, and it warns that disconnecting a streaming account removes any offline files. An account that was disconnected to free space takes its locally available copies with it.

The third is an administrator. Google states that with a work or school account, Drive for desktop may not be available, and an organisation may have to install it. On a managed Mac, the override settings in /Library/Managed Preferences/com.google.drivefs.settings.plist take precedence over anything applied per user, and AllowedAccountsPattern can restrict which accounts may sign in at all. A sign-in that is refused with correct credentials on a work machine usually lands here rather than being a fault.

The fourth is a genuinely empty account, which produces a folder that looks broken. Google notes that if Drive and the My Drive folder are empty, the Shared drives and Other computers views will not appear either.

Which settings still apply

The advanced reference lists settings that can be applied on a Mac with the defaults command, and it is worth separating the ones that still do something from the ones documented as superseded. Google notes that the defaults command maintains a plist file, and that the plist should not be edited directly because some changes might not be applied.

Setting	Still applies on current macOS
AutoStartOnLogin	Yes, a boolean that starts Drive for desktop at session login
BandwidthRxKBPS and BandwidthTxKBPS	Yes, maximum downstream and upstream, in kilobytes per second
DirectConnection	Yes, a boolean that bypasses proxy configurations
AllowedAccountsPattern	Yes, a pattern limiting which accounts may sign in
DefaultMountPoint	No, macOS controls the mount point from 12.1 onwards
ContentCachePath	No, macOS controls where cached data goes from 12.1 onwards
ContentCacheMaxKbytes	No, macOS controls the cache size from 12.1 onwards

Two details in that list are easy to misread. The bandwidth settings are kilobytes per second and Google flags this explicitly, since kilobits would be eight times smaller. And the settings live in three places with a defined precedence: host-wide in /Library/Preferences/com.google.drivefs.settings, per user in ~/Library/Preferences/com.google.drivefs.settings, and an administrator override in /Library/Managed Preferences/com.google.drivefs.settings.plist. In-app preferences take precedence over host-wide settings, and overrides take precedence over both, which is why a setting applied by hand on a managed Mac can appear to be ignored.

The bandwidth limits are the ones most worth setting on a laptop. A first sync that saturates an upstream link makes video calls unusable, and capping the upstream rate costs nothing but time.

Working with the folder from a shell

Once the path is known, the folder behaves well enough, with three habits that prevent most trouble.

Quote the path, or put it in a variable, because of the spaces and the at sign. This is the single most common cause of a script that works in one account's home directory and fails in another's.

Avoid recursive operations that read file contents unless the intent is to download everything. Copying a streamed folder elsewhere means materialising all of it, and a synchronisation tool pointed at it will do exactly that, thoroughly and without asking.

Give the path a shorter name. A symbolic link from somewhere convenient to the real location keeps commands readable and survives being retyped. It also gives one place to update if the naming ever changes again, which it has before.

None of these habits is difficult. What makes them tedious is the switching, because working out which folder a path refers to means a Finder window on one side and a terminal on the other. A window that holds both removes that translation step entirely, and comparing how file managers arrange panes, cloud locations and a shell is the shortest way to judge whether that is worth changing. For anyone maintaining this on machines set to different languages, which languages an interface is available in is a practical constraint rather than a detail.

What to change first

Get the real path once, by dragging the folder onto a terminal window, and keep it in a variable or behind a symbolic link rather than retyping it. Then decide per folder whether it should stream or mirror, since that choice and not the cloud quota is what fills the disk. If the friction is switching between a Finder window and a shell to work out which path is which, keep them together with something like Atriens.