Dropbox folder classified as "Internet" zone - triggers pop-up when moving/copying files out of it

Question

Hello everyone, this is completely driving me nuts. I have exhaustively ruled out Windows issues, so it seems to now be a Dropbox "feature" that we should have the option to toggle off: Environment * Windows 11 Pro, fully updated (clean install, July 2026) * Dropbox desktop 262.4.3183.0 * Sync root: D:\Dropbox on a local NTFS fixed drive * All content stored locally (I use Dropbox as a full local mirror, not online-only) Problem Moving or copying any file OUT of my Dropbox folder — even from D:\Dropbox\Desktop to another folder on the same physical drive — triggers the Windows Security dialog: These files might be harmful to your computer Your internet security settings suggest that one or more files may be harmful. Do you want to use it anyway? The cause is visible in File Explorer's status bar: while browsing any folder under D:\Dropbox, the zone indicator shows a globe icon and reads "Internet". Browsing any non-Dropbox folder on the same drive (e.g. D:\outlook) correctly reads "Computer". So Explorer is classifying my local Dropbox sync root as an Internet-zone location, and the copy engine then warns on every file operation that leaves it. This is not Mark-of-the-Web The test file has no Zone.Identifier alternate data stream — verified with Get-Content -Stream Zone.Identifier (returns nothing). I have also disabled MotW preservation entirely (Attachment Manager policy) and stripped existing streams across the whole tree. The warning still appears on demonstrably untagged files. Process Monitor findings Capturing explorer.exe during the drag operation: * Explorer instantiates urlmon's Security Manager {7b8a2d94-0ac9-11d1-896c-00c04fb6bfc4} and Zone Manager {7b8a2d95-...} at drag time, and queries the Dropbox packaged COM server. * A filter on Path contains Zone.Identifier captured zero events — no MotW stream is read at any point. Everything I have tried that does NOT fix it * Disabling Mark-of-the-Web (SaveZoneInformation) + Unblock-File sweep of the entire tree (incl. long-path pass) * Setting Dropbox folders to "Available offline" * Updating Windows and Dropbox (both current) * Mapping dropbox.com / dropboxapi.com / dropboxusercontent.com into the Local intranet zone * ZoneMap\ProtocolDefaults → file = 1 (Intranet) * Internet zone action 1806 = 0 (launching applications and unsafe files), HKCU * Internet zone action 1802 = 0 (drag and drop or copy and paste files), HKCU and HKLM * Attachment Manager via Group Policy: "Do not preserve zone information" = Enabled, "Default risk level" = Low, "Inclusion list for low file types" = full extension list — with gpupdate and sign-out * Accessing the same files through an NTFS directory junction (mklink /J) — Explorer canonicalizes to the registered path and still reports Internet * SEE_MASK_NOZONECHECKS=1 system environment variable + reboot * Deleting Dropbox's SyncRootManager registration key entirely (Dropbox quit, key exported, Explorer restarted) — behavior is identical even with no shell/cloud-provider registration present * Full audit of zone configuration: ZoneMap flags, Ranges, Domains, ProtocolDefaults, per-zone action values in HKCU and HKLM, policy hives — all stock/default Questions for Dropbox * Is the Internet-zone classification of the sync root intentional (e.g. hardening following the Mark-of-the-Web bypass advisory), or a regression? * Is there a supported way to have a fully-local sync root treated as a local (Computer zone) location by Explorer? * If this is by design, can Dropbox provide guidance for users who move files between local folders constantly? The current behavior trains users to click through security warnings dozens of times a day, which is worse for security than the risk it addresses. Impact I run a media production workstation and move files between Dropbox and working drives constantly. Every single operation now requires dismissing a security dialog. Workarounds like third-party file managers or PowerShell Move-Item bypass the prompt, but that means routing around Explorer to use my own local files, which isn't a reasonable steady state.

Mosscat · Answer

Walter, Hannah — thank you both, but I'd like to respectfully redirect this, because reinstalling is not going to change anything and I want to save us all the round trip.

To answer the outstanding questions directly:

Yes, this is the Cloud Files version of the app (v262.4.3183).

Yes, it was installed with admin privileges. I am the only user on this machine and I hold administrator rights.

Signing out and back in makes no difference.

The app was installed fresh this week, on a brand-new SSD, on a completely clean installation of Windows 11 Pro, with no backup or profile restored. The behavior was present immediately, on the first move of the first file. There is no legacy state to clean up — a reinstall would be reinstalling onto a four-day-old installation.

Here is a reproduction you can run internally in about 30 seconds, without any logs from me:

On any Windows 11 machine with the Cloud Files Dropbox client installed, open File Explorer and browse to any folder inside the Dropbox folder.

Look at the right-hand side of the Explorer status bar, where Windows displays the security zone of the current location. It reads "Internet", with a globe icon.

Now browse to any folder outside Dropbox on the same physical drive. It reads "Computer".

That single difference is the entire bug. Windows is classifying the Dropbox sync root as an Internet-zone location, so File Explorer's copy engine treats every file leaving it as content downloaded from the internet, and warns accordingly. If your test machines show "Internet" for the Dropbox folder too — and I expect they will — then this is reproducible on your side without any reference to my particular machine.

Why this is not a mark-of-the-web / tagged-file issue. The files I tested carry no Zone.Identifier alternate data stream; querying the stream directly returns nothing. I also disabled zone-information preservation via Group Policy and cleared existing stream data across the entire tree. Untagged files still trigger the warning. In a Process Monitor capture of the drag operation, filtered to any access of a Zone.Identifier stream, File Explorer performed zero such reads. It never looks at the file's tag. It looks at the location.

Why this is not an installation problem. I removed the Dropbox sync-root registration from Windows entirely — client shut down, registration key exported and deleted, Explorer restarted — and the behavior was identical with no Dropbox shell integration registered at all. I have also worked through every relevant Windows-side control: security zone assignments for the client's domains, the Internet zone's file-operation and unsafe-file actions in both the per-user and machine-wide locations, all of the Attachment Manager policies via Group Policy, the documented shell environment variable that suppresses zone checking, accessing the same files through an NTFS junction, changing the drive letter, and setting all content to available-offline. My entire zone configuration is at Windows defaults; nothing on this machine is misconfigured. None of it changes the behavior.

My working hypothesis, which is really the question I need answered. Microsoft's MSRC published a detailed write-up in October 2025 on hardening MapUrlToZone, the API that decides whether a path is local, intranet or internet. There is also a published mark-of-the-web bypass advisory involving Dropbox's desktop folder sharing. It looks to me as though paths under a third-party cloud sync root are now deliberately classified as Internet zone — possibly as remediation — and that no supported override exists.

So, three questions that I don't think tier-1 support can answer, and which is why I'm asking for this to be escalated to the desktop client team:

Is the Internet-zone classification of the Dropbox sync root on Windows 11 known to Dropbox, and is it intentional?

If it is intentional, is there a supported way for a user whose sync root is fully local to have Explorer treat it as a local location?

If it is not intentional, can this be raised with engineering as a defect in the Windows integration?

Why this matters commercially, since I know that carries weight internally. I have been a paying Dropbox customer for over fifteen years and I'm currently on Pro with 3 TB. My entire working life lives in that folder by design — my Windows Documents, Desktop, Pictures and Videos folders are all redirected into it, which is precisely why I lost nothing when my SSD died last weekend. That architecture is the reason I pay you. But it now means every single file operation I perform on my own computer raises a security warning. On a media production workstation, that's dozens of dialogs a day. The practical outcome is not that I'm safer — it's that I'm being trained to dismiss Windows security prompts reflexively, which is worse for everyone.

I'm not looking for a workaround; I already have several (third-party file managers and PowerShell both bypass Explorer's copy engine entirely). I'm looking for confirmation of whether this is by design, and if so, for Dropbox to offer local sync roots a way out of it.

Thank you both!

Walter · Answer

In that case, have you tried reinstalling the app @Mosscat?

If you did and this persists, you can also try an advanced reinstall.

In any case, let us know how it goes!

Mosscat · Answer

Yes, it doesnt matter if I sign in or out. In fact, I have had this problem since going from a Windows 10 pc to a Windows 11 PC last October, and then I even had the SSD go out last weekend, so I even have a clean install as of this week. I am the only account holder on the computer and with administrator privileges.