Error code 8058 on a Mac, and the copy that keeps failing

Error 8058 appears in a Finder dialog while copying, usually to or from an external drive, a NAS, or a mounted disk image. The wording varies, but the number is the useful part: 8058 is afpAccessDenied in origin, a file system level refusal rather than a damaged file.

That distinction matters, because it means the bytes in your file are almost certainly fine. Something is refusing the operation, not failing to read it. The list of things that can refuse is short.

What 8058 is actually telling you

The code comes from the Apple Filing Protocol family of errors, which is why it turns up most often on network volumes and on drives that are not natively formatted for macOS. In practice it appears in four situations:

• The destination file system cannot represent something about the file, most often its name.
• The volume is mounted read-only, or your account lacks write permission on the target folder.
• Extended attributes or resource forks cannot be written to the destination.
• The connection to a network volume dropped mid-operation.

Work through them in that order, because the first is both the most common and the easiest to miss.

Illegal characters in the filename

This is the cause people rarely suspect and it explains a surprising share of 8058 errors.

macOS permits characters in filenames that other file systems do not. Copy to an exFAT or FAT32 drive, or to a Windows-backed share, and any file whose name contains one of these will be rejected:

: " / \ | ? * < >

The colon is the frequent offender, because it appears naturally in names like Meeting: Notes or in timestamps written as 14:30. Trailing spaces and trailing full stops cause the same refusal, and they are effectively invisible in the Finder.

To find them, ask the shell rather than your eyes. In the folder you are copying from:

ls | grep '[:"/\\|?*<>]'
ls | grep -E ' $|\.$'

Rename anything those turn up, then retry. If it is a large batch, rename in place:

for f in *:*; do mv "$f" "${f//:/-}"; done

That replaces every colon with a hyphen in the current folder. Check the output of ls first so you know what you are about to change.

Path length and depth

Related, and worth checking at the same time: some destinations impose a maximum path length. A deeply nested folder structure that is fine on your Mac can exceed the limit once it is appended to the destination’s own path.

If the failing items are all buried several folders deep, try copying the top folder to the root of the destination rather than inside an existing structure, or shorten the folder names on the way.

Read-only volumes and permissions

Get Info on the destination drive and read two lines: Format, and Sharing & Permissions at the bottom.

If the format is NTFS, macOS mounts it read-only. Writes will fail, and 8058 is one of the ways that surfaces. There is no setting to change this in macOS itself; the drive needs reformatting, or the files need a different destination.

If the format is fine but permissions are wrong, the Get Info panel will say You can only read. Unlock the padlock, set your account to Read & Write, then use the panel’s action menu to apply to enclosed items if a whole folder is affected.

For external drives there is one more switch worth knowing. macOS can be told to ignore the ownership recorded on a volume, which resolves a whole category of permission problems on drives that have moved between machines. It is the Ignore ownership on this volume checkbox in the Get Info panel for the drive.

Extended attributes that will not travel

Every file on a Mac can carry extended attributes: quarantine flags on downloads, Finder tags, custom icons. Destinations that cannot store them sometimes refuse the whole copy rather than dropping the extras.

Check what a file is carrying:

xattr -l "problem file.mov"

If that prints entries such as com.apple.quarantine or com.apple.metadata:kMDItemWhereFroms, strip them from a copy and try again:

xattr -c "problem file.mov"

xattr -c clears all extended attributes from the file it names. The file contents are untouched. You lose tags and the quarantine flag, which is usually a fair trade for a copy that completes. To do it for a folder, add -r.

dot_clean is the companion fix here when the destination is FAT32, exFAT or a share, since it deals with the ._ companion files that carry those attributes across:

dot_clean /Volumes/YourDrive

Network volumes that drop

If the destination is a NAS or a shared folder, an interrupted connection produces 8058 while leaving the volume apparently mounted.

Do not retry with the Finder. Use rsync, which resumes rather than restarting and reports a real error message rather than a code:

rsync -avP --partial ~/Movies/clip.mov /Volumes/Share/Videos/

If it fails again, the message will name the actual problem, which is usually permission denied or no space left on device. Both are far more actionable than 8058.

For repeated drops, unmount and remount the share cleanly before copying, and prefer copying a folder of files over a single very large file, since a resumed folder copy loses less work.

When it is not 8058’s fault

If none of the above applies and the copy still fails, verify the source file is readable in isolation before concluding the destination is at fault:

cp "/path/to/file" /dev/null

A silent completion means the source reads fine. An error there moves you into different territory, covered in error code -36, which is the read/write failure rather than the access refusal.

If the file turns out to be damaged rather than blocked, Manatee can read what survives in a video, audio file, PDF or Office document and write a clean copy from a duplicate, leaving your original as it is. It will not help with a permissions or filename problem, which is the far more likely cause of an 8058 and is fixed with the steps above.

Questions

Why does the same file copy to my Mac’s internal drive but not the external one? Because the internal drive is APFS, which accepts the filename and the extended attributes without complaint. The external is probably exFAT or NTFS, which do not. That contrast is itself a strong diagnosis.

Can I stop macOS creating ._ files on my external drive? For network volumes there is a setting that disables them. For USB drives there is no supported switch. Running dot_clean on the volume before copying is the practical answer.

Is xattr -c destructive? It removes metadata, not content. You lose Finder tags, the download quarantine flag, and the record of where a file came from. The file itself opens exactly as before. Clear attributes on a copy if you would rather not lose the tags.

The error names a file I cannot find in the folder. It is probably a hidden companion file. Press Command-Shift-Period in the Finder to show hidden files, and look for a ._ version of the name. dot_clean removes those without you having to hunt.