xattr: No such xattr: com.apple.quarantine 이 뜰 때: -d 대신 -dr 을 쓴다When xattr says No such xattr: com.apple.quarantine: use -dr instead of -d
xattr -d com.apple.quarantine 에서 No such xattr 를 만난 독자가 오류의 뜻을 알고, 폴더와 스크립트에서 쓸 안전한 형태(-dr)를 고르게 돕는다.
시험에서 -d 는 지울 속성이 없으면 오류 문구와 종료 코드 1 을 냈고, -dr 과 -c 는 같은 상황에서 출력 없이 0 이었다. 폴더 자신에는 없고 안쪽 파일에만 있어도 -d 는 같은 오류를 내면서 안쪽 속성을 남겼다. 읽기 전용 파일은 -dr 로도 Permission denied 로 실패했다.
스크립트에는 xattr -dr com.apple.quarantine "경로" 를 쓰고, 지워졌는지는 xattr -rl 경로 | grep com.apple.quarantine 으로 확인하라.
한 줄 요약:
xattr -d는 지울 속성이 없으면 종료 코드 1 로 끝나지만xattr -dr은 없어도 0 으로 끝나므로, 격리 표시를 지우는 스크립트에는-dr을 쓴다.
바로 할 것: 내려받은 파일이나 폴더의 격리 표시는 xattr -dr com.apple.quarantine "경로" 한 줄로 지운다. 폴더면 안쪽 파일까지 지워지고, 이미 지워져 있어도 오류 없이 끝난다.
$ xattr -d com.apple.quarantine ./tool
xattr: ./tool: No such xattr: com.apple.quarantine위 오류(파일 이름 tool 은 예시)는 “지울 속성이 없다”는 안내인데 종료 코드가 1 이라, 설치 스크립트가 set -e 로 돌면 그 줄에서 멈춘다. 아래는 macOS 26.6.2(arm64)의 /usr/bin/xattr 와 bash 3.2.57 에서 잰 값이다.
용어 먼저. 확장 속성(xattr) 은 파일에 따로 붙는 이름표이고, com.apple.quarantine 은 브라우저 등으로 내려받은 파일에 맥이 붙이는 “아직 출처를 확인하지 않음” 표시다. 종료 코드는 명령이 끝날 때 남기는 숫자로 0 이 성공이고 그 밖은 실패이며, set -e 를 켠 스크립트는 0 이 아니면 거기서 멈춘다. 이 표시는 내가 만들었거나 출처를 아는 파일에만 지운다.
그 문구는 속성이 없다는 뜻이다
속성이 있는 파일과 없는 파일에 세 명령을 하나씩 돌려 종료 코드를 비교했다.
| 명령 | 격리 표시가 있을 때 | 없을 때 |
|---|---|---|
xattr -d com.apple.quarantine 파일 |
출력 없음, 0 | No such xattr 오류, 1 |
xattr -dr com.apple.quarantine 파일 |
출력 없음, 0 | 출력 없음, 0 |
xattr -c 파일 |
출력 없음, 0 | 출력 없음, 0 |
없는 경로는 -d 도 -dr 도 xattr: No such file: 경로 와 종료 코드 1 이다. 같은 명령을 두 번 치면 두 번째가 1 인 이유도 이것이다. 첫 번째에서 이미 지워졌기 때문이다.
파일을 여러 개 주면 중간 파일이 오류를 내도 멈추지 않는다. 속성이 있는 a, 없는 b, 있는 c 를 xattr -d com.apple.quarantine a b c 로 주면 b 에서만 오류를 내고 a 와 c 는 지워지며, 종료 코드는 1 이다.
폴더는 안쪽 파일이 따로 가진다
폴더에서 -d 는 폴더 자신의 속성만 지운다. 폴더·안쪽 폴더·안쪽 파일 세 곳에 속성을 붙인 뒤 xattr -d 를 하면 2곳이 남았고, xattr -dr 을 하면 0곳이 되었다. man xattr 도 -r 은 디렉터리 안 전체를 대상으로 한다고 설명한다.
더 헷갈리는 경우가 있다. 폴더 자신에는 속성이 없고 안쪽 파일에만 있을 때 xattr -d com.apple.quarantine 폴더 는 No such xattr 오류와 종료 코드 1 을 내면서 안쪽 속성 1곳을 그대로 두었다. 오류 문구만 보면 “이미 깨끗하다”로 읽히는데 실제로는 안쪽에 남아 있다. -dr 은 출력 없이 0 으로 끝나며 안쪽까지 지웠다.
공개된 질문에도 비슷한 증상이 있다. Apple 개발자 포럼의 한 글쓴이는 PNG 파일에 xattr -d 를 했더니 같은 문구가 나오자(경로는 글에 없다) 그 파일에 속성이 없다고 보고 Xcode 가 붙이는 것 같다고 추정했고, 디렉터리 전체에 xattr -rd 를 해도 반응이 없었다. 아카이브를 다시 빌드해 xattr -lr 로 보니 그 PNG 에 속성이 있었고, xattr -cr 로 해결했다. 글에서 원인은 확정되지 않았고 위 시험과 같은 원인인지는 알 수 없다. 남았는지는 아래로 센다.
xattr -rl "경로" | grep com.apple.quarantine한 줄도 안 나오면 안쪽까지 다 지워진 것이다.
스크립트가 멈추는 이유와 안전한 형태
속성이 없는 파일 하나로 set -e 를 켠 스크립트 세 가지를 돌렸다.
| 스크립트의 줄 | 결과 |
|---|---|
xattr -d com.apple.quarantine "$1" |
오류 문구를 찍고 종료 코드 1 로 멈춤 |
xattr -dr com.apple.quarantine "$1" |
다음 줄까지 가고 0 |
xattr -d com.apple.quarantine "$1" || true |
오류 문구를 찍고도 다음 줄까지 가고 0 |
설치 스크립트에서 같은 문구가 나온 공개 사례는 rayhunter 이슈다. 보고자는 두 번째 시도가 xattr: ./serial-macos-arm/serial: No such xattr: com.apple.quarantine 로 실패했다고 적었다. 이슈를 닫은 PR #219는 그 xattr -d 줄 앞에 이미 지웠다면 xattr 가 오류를 낸다는 취지의 주석을 달고 줄 끝에 || echo 를 붙였다. 한 댓글은 이 오류가 설치 여부에 영향이 없어야 한다고 했다. 그 스크립트가 set -e 였는지는 이슈에 없다. 위 표의 첫 줄은 이 글의 시험이고, 이 글은 || echo 대신 -dr 을 권한다.
|| true 는 멈춤을 막지만 모든 실패를 삼킨다. 같은 줄에 없는 경로를 주면 xattr: No such file: no-such-file 를 찍고도 스크립트는 0 으로 이어갔다. 경로 오타가 조용히 지나간다는 뜻이다. 이 글의 해석으로는 -dr 이 더 낫다. -dr 은 “속성 없음”만 조용히 넘기고 없는 경로는 1 로 알리므로, 멈춰야 할 때만 멈춘다.
-dr 로도 안 지워지는 경우와 -c 의 범위
- 읽기 전용 파일: 권한 444 파일에 속성이 있으면
-d·-dr·-c모두xattr: [Errno 13] Permission denied(-c는 두 줄) 와 종료 코드 1 로 실패하고 속성이 남았다.chmod 644 파일로 쓰기 권한을 준 뒤-d는 지웠다. 이건 “속성 없음”이 아니라 진짜 실패라-dr도-c도 숨기지 않는다. - 공백이 든 경로:
xattr -dr com.apple.quarantine my dir처럼 따옴표 없이 쓰면my와dir를 각각 없는 파일로 읽어No such file두 줄과 종료 코드 1 이 나오고 속성은 남았다."my dir"로 감싸면 지워졌다. - 심볼릭 링크:
-d는 링크가 가리키는 파일의 속성을 지웠고,-s를 붙인-ds는 링크 자신을 대상으로 해No such xattr오류를 내며 가리키는 파일의 속성을 남겼다. - -c: 격리 표시만이 아니라 시험한 속성은 모두 지운다.
com.example.keep이라는 다른 속성을 붙인 파일에서-d com.apple.quarantine은 그것을 남겼고-c는 같이 지웠다. 다른 앱이 붙인 이름표가 있을 수 있으면-d·-dr이 낫다.
시험 범위와 한계
macOS 26.6.2 arm64, /usr/bin/xattr, bash 3.2.57 에서 임시 폴더의 내 파일로 쟀고 같은 시험을 두 번 돌려 출력이 같았다. 속성 값은 xattr -w 로 직접 쓴 문자열이다. 시험 중 만든 파일에 com.apple.provenance 라는 다른 속성이 따로 붙어 있었고 이 글의 결과에서는 뺐으며, 그 속성을 지우는 것은 다루지 않는다. 맥이 앱을 막거나 여는 Gatekeeper 동작, 서명·공증, 실제로 내려받은 파일, zsh, 다른 macOS 버전은 재지 않았다. 그래서 격리 표시를 지우면 막힌 앱이 열린다고는 말하지 않는다. 이 글이 보이는 것은 xattr 명령의 오류 문구·종료 코드·지우는 범위까지다.
세 줄 요약
No such xattr: com.apple.quarantine은 지울 속성이 없다는 안내이고,xattr -d는 그때 종료 코드 1 을 낸다.- 폴더에는
-r이 있어야 안쪽까지 지워지며, 폴더 자신에 없고 안쪽에만 있어도-d는 같은 오류를 내며 속성을 남긴다. - 스크립트에는
xattr -dr com.apple.quarantine "경로"를 쓰면 속성 없음은 0, 없는 경로·읽기 전용은 1 로 구분된다.
To help a reader who met No such xattr from xattr -d com.apple.quarantine understand the message and pick a safe form (-dr) for folders and scripts.
In my tests -d printed the error and exited 1 when there was nothing to delete, while -dr and -c exited 0 silently in the same situation. When the folder itself had no attribute and only an inner file did, -d printed the same error and left the inner attribute in place. A read-only file failed with Permission denied even under -dr.
In scripts use xattr -dr com.apple.quarantine "path", and confirm it is gone with xattr -rl path | grep com.apple.quarantine.
Contents
One-line summary:
xattr -dends with exit code 1 when there is no attribute to delete, butxattr -drends with 0 even then, so use-drin scripts that remove the quarantine mark.
What to do right now: Remove the quarantine mark of a downloaded file or folder with the single line xattr -dr com.apple.quarantine "path". For a folder it clears the inner files too, and it finishes without an error even if the mark is already gone.
$ xattr -d com.apple.quarantine ./tool
xattr: ./tool: No such xattr: com.apple.quarantineThe error above (the file name tool is an example) is a notice that “there is nothing to delete”, but its exit code is 1, so an install script running under set -e stops on that line. The values below were measured with /usr/bin/xattr on macOS 26.6.2 (arm64) and bash 3.2.57.
Terms first. An extended attribute (xattr) is a label stored alongside a file, and com.apple.quarantine is the “source not yet verified” mark the Mac puts on files downloaded by a browser and similar tools. The exit code is the number a command leaves when it ends: 0 is success and anything else is failure, and a script with set -e on stops when it is not 0. Remove this mark only from files you made yourself or whose origin you know.
That message means the attribute is absent
I ran the three commands once each on a file with the attribute and on a file without it, and compared the exit codes.
| Command | When the quarantine mark exists | When it does not |
|---|---|---|
xattr -d com.apple.quarantine file |
no output, 0 | No such xattr error, 1 |
xattr -dr com.apple.quarantine file |
no output, 0 | no output, 0 |
xattr -c file |
no output, 0 | no output, 0 |
For a path that does not exist, both -d and -dr print xattr: No such file: path and exit 1. This is also why running the same command twice gives 1 the second time: the first run already deleted it.
If you pass several files, an error on one in the middle does not stop the rest. Given a (has it), b (does not) and c (has it) as xattr -d com.apple.quarantine a b c, only b prints an error, a and c are cleared, and the exit code is 1.
A folder keeps its inner files’ attributes separately
On a folder, -d clears only the folder’s own attribute. After putting the attribute on three places (a folder, an inner folder and an inner file), xattr -d left 2 places and xattr -dr left 0. The man page for xattr also says -r acts on the whole contents of a directory.
There is a more confusing case. When the folder itself has no attribute and only an inner file does, xattr -d com.apple.quarantine folder printed the No such xattr error with exit code 1 and left the 1 inner attribute alone. The message reads as “already clean”, but the inner file still has it. -dr finished with 0 and no output, and cleared the inner file.
A similar symptom shows up in a public question. In an Apple Developer Forums post, the author ran xattr -d on a PNG file and got the same message (the path is not in the post), concluded the file had no attribute and guessed that Xcode adds it, and xattr -rd on the whole directory gave no response either. After rebuilding the archive, xattr -lr showed the attribute on that PNG, and xattr -cr fixed it. The post does not settle the cause, and I cannot say it is the same cause as the test above. You can count what is left with the line below.
xattr -rl "path" | grep com.apple.quarantineIf no line appears, everything down to the inner files is cleared.
Why scripts stop, and the safe form
I ran three set -e scripts against one file with no attribute.
| Line in the script | Result |
|---|---|
xattr -d com.apple.quarantine "$1" |
prints the error and stops with exit code 1 |
xattr -dr com.apple.quarantine "$1" |
reaches the next line, 0 |
xattr -d com.apple.quarantine "$1" || true |
prints the error and still reaches the next line, 0 |
A public case of the same message in an install script is a rayhunter issue. The reporter wrote that the second attempt failed with xattr: ./serial-macos-arm/serial: No such xattr: com.apple.quarantine. The PR #219 that closed it added a comment above that xattr -d line saying that xattr errors out if the attribute was already deleted, and appended || echo to the line. One comment said this error should not affect whether it installs. The issue does not say whether that script used set -e. The first row of the table above is this article’s test, and this article recommends -dr instead of || echo.
|| true stops the halt but swallows every failure. Given a path that does not exist, the same line printed xattr: No such file: no-such-file and the script still carried on with 0. A typo in the path slips by quietly. This article’s interpretation is that -dr is better: it passes over only “attribute absent” silently and reports a missing path as 1, so it stops only when it should.
Cases -dr still leaves, and what -c covers
- Read-only file: for a file with mode 444 that has the attribute,
-d,-drand-call failed withxattr: [Errno 13] Permission denied(two lines for-c) and exit code 1, and the attribute stayed. Afterchmod 644 file,-ddeleted it. This is a real failure, not “attribute absent”, so neither-drnor-chides it. - Path with a space: written without quotes, as in
xattr -dr com.apple.quarantine my dir, it readsmyanddiras two missing files, printing twoNo such filelines with exit code 1, and the attribute stayed. Wrapped as"my dir"it was deleted. - Symbolic link:
-dcleared the attribute of the file the link points to, while-dswith-sacted on the link itself, printed aNo such xattrerror and left the target’s attribute. - -c: it deletes every attribute I tested, not only the quarantine mark. On a file with another attribute named
com.example.keep,-d com.apple.quarantinekept it and-cdeleted it too. If another app may have attached labels,-dor-dris better.
Test scope and limits
I measured on macOS 26.6.2 arm64 with /usr/bin/xattr and bash 3.2.57, using my own files in a temporary folder, and ran the same test twice with identical output. The attribute values are strings I wrote with xattr -w. Another attribute, com.apple.provenance, was attached to the files I created during the test, which I left out of this article’s results, and removing that attribute is not covered. I did not measure the Gatekeeper behavior that blocks or opens an app, signing and notarization, files actually downloaded, zsh, or other macOS versions. So I do not claim that removing the mark opens a blocked app. What this article shows stops at the error text, exit codes and deletion scope of the xattr command.
Three-line summary
No such xattr: com.apple.quarantineis a notice that there is nothing to delete, andxattr -dgives exit code 1 then.- A folder needs
-rto clear its inner files, and even when the folder itself has none and only an inner file does,-dprints the same error and leaves the attribute. - In scripts,
xattr -dr com.apple.quarantine "path"returns 0 for a missing attribute and 1 for a missing path or a read-only file, so the two are told apart.