Configure Google Drive File Stream

Configure Drive File Stream

You can specify custom options for Drive File Stream, including the default drive letter on Windows, the mount point on macOS, the cache location, bandwidth limits, and proxy settings. These configurations can be set at the user or host level, and persist when Drive File Stream restarts.

Where to update settings

To set the Drive File Stream options, you update registry keys (Windows) or use the defaults command (macOS). If you’re not familiar with making these updates, contact your administrator or check your operating system documentation. Additionally, administrators can choose to set override values that end users can't change.


User onlyHKEY_CURRENT_USER\Software\Google\DriveFS


User only~/Library/Preferences/
Override/Library/Managed Preferences/

macOS examples

Host-wide mount point:
sudo defaults write /Library/Preferences/ DefaultMountPoint '/Volumes/Google Drive File Stream'

Host-wide trusted certificates file:
sudo defaults write /Library/Preferences/ TrustedRootCertsFile /Library/MyCompany/DriveFileStream/MyProxyCert.pem

User maximum download bandwidth:
defaults write BandwidthRxKBPS -int 100

User-enabled browser authentication:
defaults write ForceBrowserAuth -bool true


Set these name/value pairs using the registry keys or defaults command, as described above. On Windows, create the registry keys if they don't already exist. On macOS, the defaults command maintains a plist file for settings. You should not modify the plist file directly, as some changes might not be applied.

Setting nameValue typeValue description
AutoStartOnLogin*DWORD (Windows)
Bool (macOS)
Start Drive File Stream automatically on session login.
BandwidthRxKBPSDWORD (Windows)
Number (macOS)
Maximum downstream kilobytes per second.
BandwidthTxKBPSDWORD (Windows)
Number (macOS)
Maximum upstream kilobytes per second.
ContentCachePathStringSets the path to the content cache location on a connected APFS, HFS+, or NTFS file system.

When Drive File Stream restarts, local data in the old content cache will move to the new content cache location. If you delete your custom setting, data will move back to the default location.

The default cache location is:

Windows: %LOCALAPPDATA%\Google\DriveFS
Mac: ~/Library/Application Support/Google/DriveFS

ContentCacheMaxKbytesQWORD (Windows)
Number (macOS)
Sets the limit on content cache size in kilobytes. The limit is capped at 20% of the available space on the hard drive (regardless of the setting value).The setting does not apply to files made available offline or files that are in the process of uploading.

This setting is only available for admins, as an override or host-wide setting.

DefaultMountPointStringWindows: Set the mounted drive letter.
You can use an environment variable to specify the drive letter.

macOS: Set the mounted drive path. You can include tilde (~) or environment variables in the path.

DisableRealTimePresence*DWORD (Windows)
Bool (macOS)
Disables real-time presence in Microsoft Office.

This can also be disabled for organizational units from the Admin console. See step 3 of Deploy Drive File Stream.

ForceBrowserAuth*DWORD (Windows)
Bool (macOS)
Use browser authentication.

If your organization uses security keys or SSO, this setting may resolve sign-in problems.

MinFreeDiskSpaceKBytesQWORD (Windows)
Number (macOS)
Controls the amount of local space used by Drive File Stream's cache. Stops writing content to the disk when free disk space gets below this threshold, in kilobytes.
Proxy settings:
DisableSSLValidation*DWORD (Windows)
Bool (macOS)
This disables validating SSL traffic. Traffic will still be encrypted, but we will not validate that the SSL certificates of the upstream servers are all valid.

Only settable host-wide.

TrustedRootCertsFileStringThis is the full path to an alternate file to use for validating host SSL certificates. It must be in Privacy Enhanced Mail (PEM) format. Set this if your users are on networks with decrypting proxies.

The file should contain the contents of the roots.pem file shipped with Drive File Stream, plus the certificates used to authenticate your proxy. These additions should correspond to the proxy-signing certificates you added to the certificate stores in your fleet of machines.

You can find roots.pem in:

\Program Files\Google\DriveFS\<version>\config\roots.pem


/Applications/Google\ Drive\ File\

Only settable host-wide.

DisableCRLCheck*DWORD (Windows)
Bool (macOS)
This disables checking Certificate Revocation Lists (CRLs) provided by certificate authorities.

If not explicitly set, this defaults to true if TrustedRootCertsFile is provided, otherwise false. Sites that use self-signed certificates for their content inspection proxies typically don’t provide a CRL.

Enterprises that specify a CRL in their proxy certificate can explicitly set DisableCRLCheck to 0 for the added check.

For boolean values, use 1 for true and 0 for false (Windows), or use true and false (macOS).

Related topics


Attackers Use Legacy IMAP Protocol to Bypass Multifactor Authentication in Cloud Accounts, Leading to Internal Phishing and BEC

Threats to cloud-based applications
 have been growing, and passwords — the traditional method used to secure accounts — are often no longer enough to protect users from the dangers that they potentially face. The need for more comprehensive security in cloud-based applications has led to vendors offering multifactor authentication (MFA) as an integral feature of their products and services. By using MFA, users limit the risk that an attacker will gain control of their accounts by spreading authentication across multiple devices.

However, while MFA provides an additional layer of security for protecting account access, it’s not a fool-proof feature. For example, a recent study from Proofpoint examined brute-force attacks against user accounts in major cloud services. The attacks reportedly took advantage of legacy email protocols, phishing, and credential dumps to bypass MFA.

Notably, attackers were able to abuse legacy protocols — most commonly the IMAP authentication protocol — to bypass even multifactor authentication. The study noted that the IMAP protocol can be abused under certain situations, such as when users employ third-party email clients that do not have modern authentication support. IMAP abuse can also be performed in two other cases: when the targets do not implement applications passwords and when it is done against shared email accounts where IMAP is not blocked and/or MFA cannot be used. The report also said these attacks can often go undetected, instead looking like failed logins rather than external attempts. Threat actors use these accounts as entry points into the system, after which lateral movement is carried out via internal phishing and BEC to expand their reach within the organization.

The six-month study saw over 72 percent of cloud tenants being targeted at least once by attackers, while 40 percent had at least one compromised account within their system. Even more concerning, 15 out of every 10,000 active user accounts were successfully breached. Hijacked servers and routers were used as the main attack platforms, with the network devices gaining access to approximately one new tenant every 2.5 days during a 50-day period.

Roughly 60 percent of the tenants involved in the study that were using Microsoft Office 365 and G Suite were targeted with the password-spraying attacks via IMAP, and 25 percent fell victim to a successful breach.

As more companies across industries adopt cloud-based services, it’s expected that cybercriminals will go after accounts for cloud-based platforms. Once an account has been compromised, whether through hacking or brute force, the account could be used to communicate with executives and their staff. Internal BEC emails could trick the targets into transferring funds and personal or corporate data or downloading malicious files. Compromised email accounts, for example, had been found replying to email threads to deliver malware. These BEC attempts can be difficult to detect given that they come from legitimate (though compromised) email accounts.

A feature such as MFA is only one part of an effective multilayered security implementation. Organizations looking to boost their security can start with these best practices:

  • Passwords still have a role to play as a component of multifactor authentication. Ensure that users have passwords that are strong and regularly changed to stay protected from brute-force attacks. This could mean includes using at least 12 characters with a mix of upper and lowercase letters, numbers, and special characters. Ask users to avoid common or easily-guessable passwords or passwords that show obvious information such as names or birthdates.
  • Educate employees on how to identify phishing attacks. Common indicators that an email is a phishing attempt include suspicious-looking email addresses and the presence of misspellings and typographical errors.
  • Furthermore, attackers often try to make their phishing attempts as convincing as possible. Thus, users should avoid giving out personal and company information unless they are absolutely certain that the person or group they are communicating with is legitimate.

Given that cybercriminals use compromised accounts and internal BEC emails, organizations should also consider the use of security solutions designed to combat the growing threat. Trend Micro’s existing BEC protection uses AI, including expert rules and machine learning to analyze email behavior and intention. The new and innovative Writing Style DNA technology goes further by using machine learning to recognize the DNA of an executive’s writing style based on past written emails. Designed for high-profile users who are prone to being spoofed, Writing Style DNA technology can detect forged emails when the writing style of an email does not match that of the supposed sender. The technology is used by Trend Micro™ Cloud App Security™ and ScanMail™ Suite for Microsoft® Exchange™ solutions to cross-match the email content’s writing style to the sender’s by taking into account the following criteria: capital letters, short words, punctuation marks, function words, word repeats, distinct words, sentence length, and blank lines, among 7,000 other writing characteristics.


Multi-Cloud Disaster Recovery Benefits and Challenges

The cloud has definitely changed both operations and data protection requirements for almost all businesses today. Not only is the cloud the basis for popular SaaS applications like Office 365, it is also used as a backup and DR target by many organizations.

Using the cloud opens up new possibilities for DR. However, one growing complication for DR and the cloud is the use of multiple clouds. Today, many businesses have adopted multiple clouds – many use both Amazon AWS and Microsoft Azure or in some cases Google Cloud or IBM Cloud. According to research done by the IBM Institute for Business Value, 85% of today’s enterprises operate in multi-cloud environments. Further, most of those organizations that don’t currently have a multi-cloud IT strategic plan to do so in the near future.  The IBM research estimates that by 2021, 98% of business will move to multiple hybrid clouds. Similarly, an ESG study found that 81% of enterprises are utilizing more than one public cloud infrastructure service provider and only 15% were using a single cloud provider.

Multi-Cloud Advantages

Using multiple clouds definitely has its advantages. Cost is one of the primary driving factors. The IBM study which consisted of 1016 executives from 19 different industries reported that 66% said multi-cloud is crucial to reducing costs. Using multiple clouds not only allows you to pick the most cost-effective options, it also allows you to pick the best cloud services to fill your own specific business needs. Adopting a multi-cloud strategy can also enable businesses to avoid vendor lock-in decreasing their dependence on a single cloud provider.

Multi-Cloud DR Planning

As a general rule, the big public cloud providers like AWS and Azure are more reliable than your own local data centers. Even so, a large-scale disaster could potentially impact both your organization and your cloud provider. Using multi-cloud disaster recovery enables you to replicate your resources to a second cloud provider in another geographic region. Typically, it’s best to use a second cloud provider that is within the same country. Crossing international boundaries can potentially bring up legal and regulatory constraints that you are probably better off without. Locating the second cloud provider in a different geographic region ensures that there is virtually no chance that both cloud providers will undergo a major outage at the same time. For instance, you could use one provider in the United States west coast region and then the east coast region with your other cloud provider.

There are challenges in using multi-cloud DR. Each different cloud provider has its own management portal and different services which require different skill sets. For IaaS implementations, you need to be aware that the different cloud providers each use different on-disk formats for their VMs. Microsoft Azure uses the VHD format while AWS uses the AMI format. As a general rule, each cloud provider’s DR services are not designed to deal with multiple cloud providers. However, some third party DR solutions are able to bridge multiple clouds making it far easier to implement a multi-cloud DR strategy. If you’re looking to implement your multi-cloud DR plan it’s best to begin with a smaller scoped POC before expanding to the rest of your organization. And like all DR plans, regular testing is a must.