Your Files Came Back — but Did Their Permissions, Executable Bits and Extended Attributes Come Back Too?

Short answer: not necessarily. A cloud service can restore the correct file bytes while failing to recreate the original filesystem state around those bytes. That state can include POSIX executable bits, mode bits, owner and group IDs, Windows NTFS ACLs, alternate data streams, macOS extended attributes, Finder tags, resource forks and other platform-specific metadata.

This distinction matters because a successful download answers only one question:

“Did I get the file content back?”

A filesystem-aware recovery has to answer several more:

“Is the script still executable? Does the service account still have access? Did the inherited ACL survive? Are the Finder tags or resource fork still there? Is the restored owner correct?”

Those are different preservation contracts.

A synced file tree is therefore not automatically a filesystem image.

First separate three permission systems that people often mix together

The word permission is overloaded in cloud storage. At least three different systems can be involved.

A user can have Can edit permission in Google Drive while the downloaded Windows file receives a completely different local NTFS ACL.

Likewise, a Linux script can be fully accessible in Dropbox but fail after restore because the executable bit was not preserved by the transfer path you used.

This is why “permissions preserved” is too vague to be useful unless the article names the exact permission system.

A checksum can pass while the restore is still operationally wrong

Suppose this script originally has:

``text -rwxr-x--- deploy.sh ``

You upload it, later download it to another machine, and calculate the same SHA-256 hash.

The hash match proves the bytes are identical.

It does not prove that:

• the execute bit is set;
• the original owner and group exist;
• the original numeric UID/GID were recreated;
• an ACL granting a deployment service account access survived;
• an SELinux label survived;
• a macOS Finder tag or quarantine xattr survived;
• a Windows alternate data stream survived.

That is not a weakness of checksums. It is simply outside what a content hash measures.

For ordinary photos and documents, byte-level restore may be enough. For scripts, software trees, server data, creative workflows and controlled-access business files, it may not be.

Dropbox publishes the clearest consumer-facing metadata preservation contract

Dropbox is unusually explicit about some filesystem metadata.

Its current documentation says Dropbox supports a defined set of extended attributes and can sync those attributes with the file. The supported list includes metadata used for Finder tags, Finder comments and some resource-fork behavior. Dropbox also explicitly lists support for a POSIX executable bit through its com.dropbox.posix.executable attribute representation.

That is materially stronger evidence than a generic statement such as “Dropbox preserves metadata.”

But the word some matters.

Dropbox does not say that arbitrary filesystem metadata is preserved without limit. Its own unsupported-file guidance points users back to the specific supported-extended-attributes list rather than promising full filesystem replication.

So the correct interpretation is:

Dropbox intentionally preserves a documented subset of filesystem-visible metadata, including the POSIX executable bit and selected macOS attributes. It is not a general-purpose NTFS/POSIX filesystem image format.

That distinction is particularly useful for developers using Linux or macOS.

What Dropbox's documented support does not prove

It does not automatically prove preservation of:

• arbitrary POSIX ownership (uid / gid);
• every chmod mode bit;
• every Linux xattr namespace;
• every Windows NTFS ACL entry;
• every Alternate Data Stream;
• every macOS xattr;
• local ACL inheritance semantics on a different destination filesystem.

If any of those are part of your recovery requirement, test them explicitly.

Apple File Provider can carry executable/read/write flags and some xattrs — but Apple still sets boundaries

Apple's File Provider framework exposes a much richer filesystem-metadata model than many people realize.

NSFileProviderFileSystemFlags includes flags for whether a user can:

• read an item;
• write an item;
• execute an item;
• see it as hidden.

File Provider also exposes extended attributes, Finder-related metadata and tag data.

That sounds close to a filesystem round trip, but Apple documents an important limit: the system decides which extended attributes are syncable. Apple also caps syncable extended attributes to roughly 32 KiB per item; attributes beyond that can be made non-syncable.

So there are two useful conclusions.

First, it is wrong to claim that File Provider only knows filename, size and date. It can represent richer local metadata.

Second, it is equally wrong to claim that an iCloud/File Provider workflow therefore preserves arbitrary macOS filesystem metadata without limits.

The framework itself tells us there is a filtering policy.

iCloud Drive-specific caution

Apple's File Provider framework is the architecture used by modern cloud-file providers on macOS, including Apple's own cloud-file integration, but a framework capability is not the same thing as a consumer guarantee that every iCloud Drive round trip preserves every xattr and ACL exactly.

CloudScope therefore treats the Apple evidence as:

• documented platform capability: executable/read/write/hidden flags and selected extended attributes can be represented;
• documented limit: the system chooses syncable xattrs and caps their total size;
• not publicly proven: arbitrary full APFS metadata cloning for every iCloud Drive file.

That is the evidence boundary.

OneDrive and SharePoint permissions are cloud roles, not a byte-for-byte copy of NTFS security descriptors

Microsoft's migration documentation makes the model difference unusually clear.

When Microsoft migrates Windows file-share content into SharePoint or OneDrive, source permissions are mapped into Microsoft 365 access roles. Microsoft's current file-share migration guide says the most restrictive share/NTFS permission is used to determine the resulting cloud permission level, and advanced NTFS permissions are removed.

The migration tool can preserve simpler permission intent such as Read, Write or Full Control by mapping it into SharePoint/OneDrive roles. That is useful, but it is a translation.

It is not a full NTFS security-descriptor clone.

This matters because NTFS ACLs can contain concepts such as:

• inherited versus explicit ACEs;
• allow and deny entries;
• object-specific permissions;
• local machine or domain SIDs;
• ownership;
• auditing entries.

A cloud collaboration system cannot blindly reproduce all of that on an unrelated device and filesystem.

What happens when a file is downloaded again?

Once the cloud file becomes a local Windows file again, the destination Windows filesystem has to assign local security metadata. That local ACL can depend on:

• the folder the file is materialized into;
• the local Windows account;
• inheritance rules;
• OneDrive/File On-Demand implementation details;
• local security policy.

Do not assume that an NTFS ACL applied on Computer A is a portable property that ordinary OneDrive sync will recreate identically on Computer B.

If NTFS ACL preservation is business-critical, Microsoft's own migration stack is evidence that you need a permission-aware migration plan, identity mapping and post-migration validation — not merely drag-and-drop sync.

Google Drive exposes cloud permissions and object metadata, not a POSIX/NTFS filesystem clone contract

Google Drive's API exposes a substantial metadata model:

• item ID;
• filename;
• created and modified times;
• owner-related information;
• custom properties;
• revisions;
• cloud permissions and capabilities;
• image/media metadata.

Google's permissions resource is explicitly about who can access a Drive item — users, groups, domains or public roles.

That is cloud authorization.

In the current public Drive API metadata model, CloudScope did not find a documented general-purpose field representing arbitrary:

• POSIX mode bits;
• UID/GID;
• Linux ACLs;
• NTFS security descriptors;
• arbitrary filesystem xattrs.

Absence from the public API is not proof that Google internally stores no related local metadata. It is evidence that Drive's public object model does not offer a general filesystem-metadata preservation contract comparable to a tar archive, filesystem snapshot or specialized backup format.

There is another practical clue: Drive for desktop officially supports Windows and macOS, but not Linux. Google also documents its virtual Drive as a FAT-style filesystem surface in its desktop system-requirements material. That alone should stop a Linux administrator from treating Drive for desktop as a transparent POSIX filesystem backup mechanism.

Google Drive can be an excellent document and collaboration store. That does not make it a portable Linux filesystem image.

pCloud's public metadata model is storage-oriented, but it does not expose a full POSIX/NTFS metadata contract

pCloud's public API metadata structure includes fields such as:

• file/folder IDs;
• name;
• parent folder;
• created and modified timestamps;
• size;
• content type;
• content hash;
• ownership/share state;
• cloud-side access booleans such as canread, canmodify, candelete and cancreate for shared items.

Those permission booleans describe pCloud object access.

They are not POSIX mode bits or NTFS ACL entries.

Likewise, pCloud's uploadfile API lets a migration tool explicitly set mtime and ctime, which is useful for preserving timestamp intent, but its documented metadata schema does not expose a general UID/GID/mode/xattr/NTFS-ACL round-trip contract.

So pCloud should not be sold as a magic filesystem-preservation layer.

Its advantage in this use case is architectural rather than magical: pCloud is storage-first, supports Linux as a first-party desktop platform, and exposes file-level metadata APIs that can help build verification tooling. But if your restore requirement says:

“This Linux tree must come back with the exact owner, group, mode, ACL and xattr set,”

ordinary pCloud Sync or Drive should not be the only backup artifact.

Use a filesystem-aware archive or backup representation for that requirement.

The Big Five evidence matrix

This is why the provider logo is not the first question.

The first question is:

Which metadata must survive for the restored workload to function?

When permissions actually matter

For many consumer folders, they barely matter.

Photo and video archive

You may care about:

• file bytes;
• filename;
• folder structure;
• embedded EXIF/video metadata;
• created/modified time.

You may not care whether the restored JPEG inherits the identical source-machine ACL.

Shell scripts and developer tools

You may care about:

• executable bit;
• line endings;
• symlink semantics;
• xattrs;
• owner/group;
• exact case-sensitive paths.

A restore that drops one executable bit can break a deployment workflow even when every hash matches.

Application bundles and macOS workflows

You may care about:

• resource forks;
• Finder info;
• tags;
• extended attributes;
• quarantine or signing-related metadata;
• package structure.

A plain browser upload/download is a very different preservation path from a native client with File Provider metadata support.

Windows file server migration

You may care about:

• inherited ACLs;
• explicit ACLs;
• user/group identity mapping;
• deny entries;
• ownership;
• auditing.

That is an enterprise migration problem, not a generic “copy folder to OneDrive” problem.

Browser upload is usually the weakest assumption for filesystem preservation

A browser upload has a simple job: send file content and selected browser-visible metadata into a web service.

Browsers do not act as privileged filesystem imaging tools.

So if a provider's desktop client documents preservation of special filesystem metadata, do not assume the web uploader automatically provides the same semantics.

This is especially important with Dropbox, where the desktop client has explicit support for selected extended attributes. The safe question is not:

“Does Dropbox support executable bits?”

It is:

“Does the exact transfer path I am using preserve the executable bit?”

The same distinction applies to migration APIs, third-party transfer tools and ZIP exports.

Archive formats can preserve more metadata — but only if you choose the right format and options

If exact filesystem metadata matters, one common strategy is to package the tree into a filesystem-aware archive before sending it to cloud storage.

For Unix-like systems, a correctly created tar archive can preserve more filesystem semantics than uploading each file independently. Depending on the platform and implementation, options may preserve:

• mode bits;
• ownership information;
• timestamps;
• ACLs;
• extended attributes.

But this is not automatic either.

A generic ZIP file should not be assumed to preserve the same Unix/ACL/xattr semantics as a carefully configured tar/backup tool.

Windows ACL preservation may require Windows-native backup, robocopy/migration tooling, VSS-aware backup, system-state backup or another ACL-aware product.

The key principle is:

Put the filesystem metadata inside a preservation format whose contract you can test, then store that artifact in cloud storage.

That turns the cloud provider into the durable storage layer without asking it to understand every source filesystem feature.

Build a metadata manifest before a high-value migration

For technical archives, create a manifest before upload.

A useful Unix-oriented manifest might capture:

``text path size sha256 mode uid gid mtime ACL hash / ACL text selected xattrs ``

On Windows, a migration manifest can capture:

``text path size sha256 owner ACL / SDDL creation time modified time ``

You do not necessarily need to preserve every field.

The value of the manifest is that it forces you to decide which fields matter before the source disappears.

Without a manifest, the post-migration question becomes subjective:

“Looks OK — did anything important change?”

With a manifest, the question becomes testable.

The restore test should validate behavior, not just existence

For a Linux toolchain, test:

1. restore to a clean filesystem;
2. compare checksums;
3. compare mode bits;
4. compare owner/group where applicable;
5. inspect ACLs/xattrs you declared important;
6. execute a representative script;
7. run the application or build process.

For a Windows business share, test:

1. restore a representative folder;
2. validate who can read it;
3. validate who can modify it;
4. check inherited versus explicit permissions;
5. test a user who should be denied;
6. test the actual business application.

For macOS, test:

1. restore representative tagged files;
2. compare Finder tags/comments if important;
3. inspect selected xattrs;
4. open any package/bundle that depends on metadata;
5. verify the file behaves as expected.

A backup that cannot recreate the behavior you care about has not met the restore contract.

Do not confuse cloud sharing permissions with restored local permissions

This is worth repeating because it causes expensive mistakes.

Suppose a SharePoint file is shared with Alice as Can edit.

That does not mean Windows must materialize the file with an NTFS ACL containing Alice's Windows SID.

Suppose a pCloud shared folder says another user can read and modify an object.

That does not mean the file downloaded to Linux must receive that user's UID/GID or POSIX ACL.

Suppose Google Drive says an item is owned by one account and editable by another.

That is a cloud collaboration relationship, not a Unix ownership model.

Cloud authorization and local filesystem authorization solve different problems.

A practical decision rule

Ordinary personal documents

Use normal cloud sync. Verify file content and important timestamps. Do not over-engineer ACL preservation if the destination device will naturally assign appropriate local permissions.

Developer projects

Use version control for source history and collaboration. If executable bits or symlinks matter, verify them explicitly. For release artifacts or irreplaceable local state, keep a filesystem-aware archive in addition to sync.

Linux server trees

Do not make ordinary consumer cloud sync your only filesystem backup. Use tar/backup/snapshot tooling that preserves the metadata your service requires, then store verified backup artifacts in cloud storage.

Windows departmental shares

Treat this as a permission migration project. Map identities, decide how NTFS ACLs translate to cloud roles, and validate effective access after migration.

macOS creative archives

Identify whether Finder tags, resource forks, package metadata or xattrs matter. Use a tested native or archive workflow if they do.

The safest rule: define the restore contract before deleting the source filesystem

A cloud migration should not end at:

“All 85,000 files are present.”

For metadata-sensitive data, it ends when the declared restore contract passes.

Use this sequence:

1. Inventory the source filesystem.
2. Declare which metadata classes matter.
3. Choose a transfer/archive method that claims to preserve those classes.
4. Upload without deleting the source.
5. Restore to a clean target.
6. Compare bytes and required metadata separately.
7. Run a functional workload test.
8. Only then retire the original source.

That is slower than trusting a green check mark.

It is also the difference between storing files and preserving a filesystem.

Sources

• Dropbox Help — What extended attributes does Dropbox support?: https://help.dropbox.com/sync/extended-attributes
• Dropbox Help — Fix Dropbox files not syncing: https://help.dropbox.com/sync/files-not-syncing
• Microsoft Learn — Migrate file shares to SharePoint and OneDrive: https://learn.microsoft.com/en-us/sharepointmigration/fileshare-to-odsp-migration-guide
• Microsoft Learn — SharePoint Migration Tool settings: https://learn.microsoft.com/en-us/sharepointmigration/spmt-settings
• Google Drive API — Files resource: https://developers.google.com/workspace/drive/api/reference/rest/v3/files
• Google Drive API — Permissions resource: https://developers.google.com/workspace/drive/api/reference/rest/v3/permissions
• Google Drive Help — Drive for desktop system requirements and supported filesystems: https://support.google.com/drive/answer/2375082
• Apple Developer — NSFileProviderItemProtocol extendedAttributes: https://developer.apple.com/documentation/fileprovider/nsfileprovideritemprotocol/extendedattributes
• Apple Developer — NSFileProviderFileSystemFlags: https://developer.apple.com/documentation/fileprovider/nsfileproviderfilesystemflags
• pCloud Developers — Metadata structure: https://docs.pcloud.com/structures/metadata.html
• pCloud Developers — uploadfile: https://docs.pcloud.com/methods/file/uploadfile.html