.DS_Store and ._ files on remote servers

Two different files from two different mechanisms, routinely treated as one. Deleting the wrong one throws away metadata; the famous fix only ever addressed the other.

Written and maintained by OnePasswordManager Ltd. Last checked against current documentation on 21 August 2026.

What is .DS_Store?

A .DS_Store file is Finder's record of how you last looked at a folder: icon positions, window size, sort order, view mode, background. Finder writes one into any directory it displays, including directories that are not on your Mac. The file is per-folder and it belongs to whoever browsed the folder, not to the folder's contents — which is why a .DS_Store committed to a shared repository causes noise for everyone and means nothing to any of them. It also carries a genuine disclosure risk that has nothing to do with tidiness: because it lists the names of items the folder contained when Finder last saw it, a .DS_Store left in a published web root can be downloaded and parsed to reconstruct the directory listing, including files the server would not otherwise reveal.

What is a file called ._something?

A file whose name begins with ._ is an AppleDouble sidecar, and it exists because the destination filesystem cannot store everything macOS wants to attach to a file. macOS files can carry extended attributes, access control lists, a resource fork and Finder information, and most non-Apple filesystems have nowhere to put those. Rather than discard them, macOS splits the file in two: the data goes in the file you named, and everything else goes in a companion file with ._ prefixed to the same name. The manual page for copyfile(3) describes the format's contents precisely when documenting how to unpack one — it restores "the extended attributes, ACLs, resource fork, and FinderInfo data". So a ._report.pdf next to report.pdf is not a duplicate and not a stray temp file: it is the other half of the same document, as macOS sees it.

How to confirm that is what you are looking at

macOS ships a tool whose entire job is reuniting the two halves, and its manual page is the plainest available statement of what these files are. The dot_clean(1) description reads: "For each dir, dot_clean recursively merges all ._* files with their corresponding native files according to the rules specified with the given arguments." If you run it on a directory tree you have copied off a server, the sidecars are folded back into the files they belong to and disappear. That is a much better outcome than deleting them blindly, which silently discards whatever metadata they were carrying.

dot_clean -m /path/to/directory

Why do they appear on my server at all?

Because from macOS's point of view a mounted remote directory is a place to put files, and the same rules apply. If Finder displays a remote folder, it writes its view settings there. If you copy a file that has extended attributes onto a filesystem that cannot hold them, macOS creates the sidecar. Neither behaviour is specific to SSH or SFTP — it happens over SMB, over a USB stick formatted as FAT, and over any mounted remote volume. What is specific to remote servers is the consequence: the files land in a place other people and other systems read, where a build script, a deployment, a find-based cleanup or a directory listing will encounter them and nobody involved knows what they are.

How do I stop them being created?

The command everyone quotes is real, and its scope is narrower than the pages quoting it suggest. Apple published a note titled "Mac OS X v10.4 and later: How to prevent .DS_Store file creation over network connections" in 2005, which is now available only in archived form. It documents the following setting and states that it applies to network connections — the protocols enumerated are SMB/CIFS, AFP, NFS and WebDAV. It also states plainly that it does not stop creation on local volumes and does not remove files that already exist.

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

Two honest caveats that pages recommending this command tend to omit. First, it addresses .DS_Store only; it has no effect on ._ sidecars, which come from a different mechanism entirely. Second, the documented scope is that list of network protocols, and a volume mounted through a modern file provider is not obviously on it — so treat the setting as worth applying and then verify on your own server whether new .DS_Store files stop appearing, rather than assuming. Log out and back in after setting it; the value is read at login.

The reliable place to deal with it is the server

Client-side settings depend on every Mac touching the share being configured correctly, which in a team of any size will not stay true. Handling it on the server holds regardless of who connects. For a repository, add both patterns to .gitignore — a global one at ~/.gitignore_global saves repeating it. For anything you synchronise, exclude them at the point of transfer. And for a directory that is already polluted, remove them in one pass.

printf '.DS_Store\n._*\n' >> ~/.gitignore_global
git config --global core.excludesfile ~/.gitignore_global

rsync -a --exclude='.DS_Store' --exclude='._*' ./src/ user@server:/var/www/

find /var/www -name '.DS_Store' -o -name '._*' -print

Run the find with -print first and read the list before you add -delete. On a directory tree you did not create, a ._ file may be carrying metadata something still depends on, and dot_clean is the non-destructive way to resolve those. On a web root the .DS_Store files should simply go, and it is worth configuring the web server to refuse to serve them at all, since deleting them today does not stop a new one appearing the next time somebody opens the folder in Finder.

Does it depend on which tool I use?

The answer depends on whether Finder is involved and on how the tool writes files. Anything that presents the server as a volume you browse in Finder invites Finder to write .DS_Store, because that is what Finder does to folders it displays. A transfer client with its own file browser window does not, since Finder never sees the remote directory. Sidecar ._ files are a separate question: they appear when a copy operation preserves macOS metadata onto a destination that cannot store it natively, so they depend on the copying mechanism rather than on the interface. This is one of the practical differences between mounting a server and browsing it, and it is covered from the other direction in SFTP clients for Mac.