How to Fix SMB File Copies That Lose Finder Tags on macOS

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How to Fix SMB File Copies That Lose Finder Tags on macOS - Zima Store Online

SMB copies lose Finder tags when the file data arrives but the macOS extended attributes carrying those tags are not preserved or translated correctly.

Finder tags are metadata, not part of the ordinary file payload. On a home NAS, the copy path can involve the macOS client, SMB named streams, Samba Apple extensions, server-side copy behavior, the destination filesystem, and later sync or migration tools. Test one tagged file through the exact failing route, inspect the tag attribute before and after the copy, then fix the first layer that drops or remaps it.

Prove the File Copied but the Tag Attribute Did Not

Create a test file with one unique Finder tag and copy it to the SMB share using the same Finder action that loses metadata. Compare the file contents and the tag attribute on the Mac before the copy and after reading the destination back through SMB.

Carbon Copy Cloner documents that Finder tags are extended attributes rather than ordinary filename or file-content data.

If the tag remains visible on the source but disappears only on the SMB copy, the issue is metadata transport. If the tag also disappeared from the source, investigate the application or local filesystem instead.

Check Whether the Copy Path Preserves Extended Attributes

Do not assume that a successful byte-for-byte file copy also preserves xattrs. Compare Finder copy, another Mac copy tool, and any rsync, sync, or backup process that later touches the same NAS file.

A detailed xattr overview warns that tools can drop extended attributes unless their metadata-preservation behavior is explicitly supported or enabled.

If Finder preserves the tag but a later sync removes it, leave the SMB server unchanged and fix that downstream tool. If Finder itself loses the tag immediately, continue into Samba and server storage.

Verify Samba Is Using the Apple Metadata Path

On a Samba-based home server, inspect whether the share enables the Apple interoperability modules and a compatible extended-attribute or stream backend. Compare the affected share with one known-good Mac-oriented share if available.

A home-server Samba note explains that fruit carries Mac metadata instead of treating a generic Samba share as identical to Apple’s own SMB behavior.

Change one share setting at a time and retest the same tagged file. Avoid copying a large photo or project library until the new test file keeps its tag after disconnecting and reconnecting the SMB share.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Check the Destination Filesystem and Metadata Storage Mode

Samba may translate macOS metadata into filesystem xattrs, named streams, or AppleDouble-style companion data depending on configuration. The destination filesystem therefore has to support the storage mode the share is using.

A migration from macOS Server to Samba describes the work needed for Mac-compatible Samba behavior rather than assuming ordinary Linux file sharing automatically preserves every Mac-specific feature.

Check whether the metadata exists on disk even when Finder does not display it. A stored-but-untranslated attribute points to Samba mapping; no metadata at all points earlier in the copy or server-write path.

Do Not Delete AppleDouble Sidecars Until Their Role Is Proven

Some paths store Mac metadata in ._ AppleDouble files. Cleanup jobs that remove those files as clutter can silently remove metadata even though the primary documents remain intact.

An AFP-to-SMB migration guide warns that AppleDouble may carry metadata and should not be discarded blindly during protocol migration.

Test on copies before converting or deleting sidecars. If the tags depend on those files, migrate them into a supported SMB metadata representation before cleanup.

Verify the Tags Survive Copy, Reconnect, and a Second Mac

After changing the copy or Samba path, copy a fresh tagged file, disconnect the share, reconnect it, and check the tag again. Then inspect the same file from another Mac account or client so a local Finder cache does not create a false pass.

A macOS storage explainer notes that xattrs carry file-specific metadata and therefore must survive the actual filesystem and protocol path, not only the current Finder window.

The fix is complete when a tagged file survives repeated SMB copies and reconnects without creating an untracked sidecar dependency. The related ZimaSpace guide to an unavailable Time Machine SMB backup covers the broader Mac-to-NAS SMB boundary when metadata works but the share itself becomes unavailable.

Frequently Asked Questions

Are Finder tags stored in .DS_Store?

The file’s tag value is stored as an extended attribute. Finder can also keep folder-specific metadata in .DS_Store, so the two should not be treated as interchangeable.

Will preserving file contents automatically preserve Finder tags?

No. A tool can copy the data fork correctly while dropping extended attributes or Apple-specific streams. Test metadata preservation explicitly.

Should I enable every Samba fruit option at once?

No. Use a known-good test file and change only the settings required by the share’s metadata model. Broad changes make it harder to identify which layer fixed or broke the tags.