왜 SMB 파일 공유가 윈도우에서는 작동하지만 macOS에서는 실패할까요?

SMB 파일 공유가 Windows에서는 작동하지만 macOS에서는 실패할 경우, 서버가 완전히 오프라인 상태는 아닐 가능성이 큽니다. Windows는 이미 공유가 존재하며 적어도 한 클라이언트가 접근할 수 있음을 보여주었습니다. 차이는 사용 중인 주소, 저장된 자격 증명, 계정 신원, SMB 협상, 서명 요구 사항, 공유 권한 또는 Finder가 네트워크 폴더를 처리하는 방식에 있을 가능성이 높습니다.

가장 안전한 문제 해결 방법은 두 컴퓨터가 동일한 대상을 테스트하도록 하는 것입니다. 정확한 서버 IP와 공유 이름부터 시작하여 호스트 이름 해석, 인증, 보안 협상, 권한, Samba 호환성 및 Finder 성능 순으로 진행하세요. Mac에서 레거시 SMB를 활성화하거나 서명을 비활성화하는 것부터 시작하지 마세요.

먼저 Windows와 macOS가 동일한 공유를 열고 있는지 확인하세요

Windows는 이미 다음과 같은 매핑된 드라이브를 가지고 있을 수 있습니다 \\192.168.1.50\Documents, Mac 사용자가 Finder에서 서버 아이콘을 클릭하거나 단지 smb://server-name이 테스트들은 서로 다른 주소, 계정 또는 공유 경로를 가리킬 수 있습니다.

Windows 컴퓨터에서 작동하는 서버 주소, 공유 이름, 사용자 이름 및 연결에 IP 주소 또는 호스트 이름이 사용되는지 기록하세요. 그런 다음 Finder에서 Command + K를 누르고 smb://192.168.1.50/Documents와 같은 동등한 경로를 입력하세요.

Mac이 정확한 IP 및 공유 경로를 열 수 있다면 SMB 서비스와 공유는 기본적으로 접근 가능합니다. 남은 문제는 검색, DNS, 저장된 자격 증명 또는 원래 경로 형식일 가능성이 높습니다.

Finder 검색에 의존하기 전에 서버 IP를 사용하세요

Windows와 macOS는 항상 네트워크 장치를 같은 방식으로 검색하지 않습니다. 서버는 Windows 파일 탐색기에서는 자동으로 나타날 수 있지만 Finder 네트워크 보기에는 나타나지 않을 수 있습니다.

이것이 반드시 macOS가 SMB를 사용할 수 없다는 의미는 아닙니다. 자동 검색은 DNS, mDNS, NetBIOS 호환 동작, 라우터 이름 해석 및 파일 서버에서 발표하는 내용에 따라 달라집니다. 직접 액세스를 통해 smb://IP/share 대부분의 검색 계층을 우회합니다.

IP가 작동하면 SMB 구성을 변경하지 말고 이름을 조사하세요. 호스트 이름이 올바른 주소로 해석되는지, 서버가 mDNS를 통해 자신을 광고하는지, Mac이 오래된 주소를 캐시하고 있는지 확인하세요.

서버 비밀번호를 재설정하기 전에 저장된 자격 증명을 삭제하세요

macOS는 키체인에 저장된 SMB 자격 증명을 재사용할 수 있습니다. 비밀번호가 변경되었거나 동일한 서버에 IP와 호스트 이름 모두로 접근하거나 사용자가 이전에 게스트 액세스를 선택한 경우 혼란스러울 수 있습니다.

마운트된 공유를 분리하고, 키체인 접근을 열어 서버 호스트 이름, IP 주소, 공유 이름을 검색하세요. 오래된 항목을 제거한 후 다시 연결하고 SMB 서버에 실제로 존재하는 계정을 입력하세요.

Apple의 문제 해결 단계는 올바른 사용자 이름, 비밀번호, 호스트 이름 및 공유 액세스 확인부터 시작합니다. 해당 페이지는 macOS에서 호스팅되는 SMB 환경을 다루지만, 여기서도 인증 성공과 특정 공유 사용 권한은 별개의 확인 사항입니다.

Mac이 올바른 계정 ID를 보내고 있는지 확인하세요

Windows 컴퓨터는 로그인한 계정으로 자동 연결할 수 있습니다. macOS에서는 로그인 대화 상자가 기본적으로 Mac 사용자 이름으로 설정될 수 있는데, 이는 Windows, NAS 또는 Samba 서버에 존재하지 않을 수 있습니다.

서버는 로컬 서버 계정, Samba 사용자, Microsoft 계정, Active Directory ID 또는 머신, 작업 그룹, 도메인 이름으로 자격이 부여된 계정을 기대할 수 있습니다. 환경에 따라 유효한 형식은 다음을 포함할 수 있습니다 username, SERVER\username또는 DOMAIN\username.

SMB 비밀번호로 Windows Hello PIN을 사용하지 마세요. PIN은 일반적으로 Windows 장치를 로컬에서 잠금 해제하지만, 파일 서버는 기본 계정 비밀번호나 다른 지원되는 인증 방법이 필요합니다.

Mac에서 포트 445에 도달할 수 있는지 확인하기

로그인 프롬프트가 나타나기 전에 정확한 SMB 경로가 실패하면 Mac이 TCP 포트 445에서 서버에 도달할 수 있는지 확인하세요. Windows는 다른 네트워크 인터페이스, VLAN, 방화벽 프로필 또는 저장된 경로를 사용할 수 있습니다.

macOS에서는 다음과 같은 간단한 테스트를 할 수 있습니다 nc -vz 192.168.1.50 445 포트가 연결을 수락하는지 여부를 보여줄 수 있습니다. 타임아웃이 발생하면 라우팅, VLAN 격리, 방화벽 규칙 또는 예상 인터페이스에서 수신 대기하지 않는 서버를 가리킵니다.

포트 445에 접근할 수 있지만 인증에 실패한다면, 물리적 네트워크 경로는 더 이상 주요 의심 대상이 아닙니다. 자격 증명, SMB 방언, 서명 및 공유 권한으로 문제를 이동하세요.

SMB 방언 협상은 두 클라이언트 간에 다를 수 있습니다

오래된 라우터, 레거시 NAS 장치, 구식 Samba 설치는 한 Windows 컴퓨터는 수락하지만 최신 Mac에서는 성공적으로 협상하지 못하는 프로토콜 조합을 제공할 수 있습니다.

장기적인 해결책은 SMB1이나 클라이언트 측 호환성 예외에 의존하지 않고 서버를 SMB2 및 SMB3로 구성하는 것입니다. 최신 Samba 구성은 SMB2를 최소, SMB3를 최대 프로토콜로 명시적으로 설정할 수 있어 Windows와 macOS가 명확한 협상 범위를 갖게 됩니다.

Windows 호환성이 서버 구성이 최신임을 증명한다고 가정하지 마세요. SMB1 또는 레거시 인증이 해당 Windows 컴퓨터에서 수동으로 활성화되었을 수 있으며, Mac은 다른 보안 기준을 사용하고 있을 수 있습니다.

서명 및 인증 요구 사항은 일치해야 합니다

SMB 서명은 메시지가 전송 중에 변경되지 않았음을 검증합니다. 클라이언트와 서버가 SMB 보안 기능, 인증, 서명 또는 validate-negotiate 동작에 대해 의견이 다르면 연결이 실패할 수 있습니다.

Apple은 macOS에서 SMB 3가 기본 연결 방식이며, 인증된 SMB 3 세션은 서명을 사용하고 특정 디렉터리 기반 환경에서는 SMB 3 validate-negotiate 및 세션 서명 검사 중에 실패할 수 있다고 언급합니다. 이는 특정 Open Directory 사례이지만, 보안 협상 중에 기본 네트워킹이 아닌 “연결 실패” 메시지가 발생할 수 있음을 보여줍니다.

설정하지 마세요 signing_required=no 또는 validate_neg_off=yes 첫 번째 응답으로서. 검증 또는 서명을 비활성화하면 가로채기 방어가 줄어들 수 있습니다. 먼저 서버가 최신 SMB 버전을 지원하고 일관된 서명 정책을 가지고 있는지 확인하세요.

게스트 액세스가 실제로 Windows가 사용하는 방식이 아닐 수 있습니다

Windows 공유는 암호 프롬프트 없이 열릴 수 있어 사용자가 이를 게스트 공유로 오해할 수 있습니다. 실제로 Windows는 Credential Manager에 저장된 자격 증명이나 로그인한 계정을 재사용할 수 있습니다.

Windows 클라이언트에서 활성 SMB 세션을 확인하거나 매핑된 공유를 끊고 명시적으로 다시 연결하세요. 그런 다음 Mac에서 동일한 서버 측 계정을 사용하세요.

공유가 의도적으로 익명이라면 서버가 게스트 접근을 허용하고 게스트 사용자를 적절한 파일시스템 권한이 있는 계정에 매핑하는지 확인하세요. 해결되지 않은 자격 증명 문제를 우회하기 위해 광범위한 게스트 접근을 활성화하는 것은 피하세요.

공유 권한과 파일시스템 권한은 별개입니다

Mac이 인증에 성공했지만 빈 공유를 보거나 “권한 거부” 메시지를 받거나 폴더를 읽기 전용으로 마운트할 수 있습니다. 이 경우 SMB 연결은 성공했지만 파일 권한 인증이 실패한 것입니다.

대부분 파일 서버는 최소 두 계층을 평가합니다. 공유 구성은 어떤 사용자가 공유에 접근할 수 있는지 결정하고, NTFS 권한, POSIX 소유권 또는 파일시스템 ACL은 그 사용자가 읽기, 생성, 수정, 삭제할 수 있는 권한을 결정합니다.

같은 서버 계정으로 Windows와 macOS를 테스트하세요. 한 클라이언트가 다른 사용자나 그룹을 사용하면 결과를 직접 비교할 수 없습니다. 또한 Mac이 실수로 게스트로 연결되었고 Windows는 인증된 계정을 사용했는지 확인하세요.

Samba는 macOS 메타데이터 지원을 개선할 필요가 있습니다

서버가 Samba를 사용하는 경우 기본 Windows 호환성이 이상적인 macOS 동작을 보장하지 않습니다. Finder와 Mac 애플리케이션은 확장 속성, Finder 메타데이터, 대체 데이터 스트림, 리소스 포크를 사용하며, Windows 클라이언트는 이를 요청하지 않을 수 있습니다.

Windows와 macOS 혼용 사용을 위한 Samba 설정은 macOS 메타데이터를 fruit와 streams_xattr를 통해 저장할 수 있습니다. 일반적인 구성은 Apple 전용 메타데이터를 표현하면서도 일반 Windows 접근을 방해하지 않도록 vfs objects = catia fruit streams_xattr를 포함할 수 있습니다.

이 모듈들은 공유가 마운트되었지만 파일 이름, 확장 속성, 리소스 포크, 타임머신 동작 또는 Finder 메타데이터가 일관되지 않을 때 가장 관련이 있습니다. 잘못된 비밀번호나 접근 불가능한 서버 문제를 해결하는 대체 수단은 아닙니다.

Finder 성능 문제는 연결 실패처럼 보일 수 있습니다

가끔 공유가 연결되지만 Finder가 빈 디렉터리를 표시하거나, 큰 폴더를 열 때 몇 초 동안 로딩 표시가 돌거나 응답하지 않는 경우가 있습니다. 사용자는 이를 “SMB가 고장났다”고 느끼지만 실제로는 마운트 자체는 성공한 상태입니다.

Finder는 파일 메타데이터, 권한, 미리보기, 리소스 정보 및 디렉터리 업데이트를 요청할 수 있습니다. 이러한 작업은 특히 대용량 폴더나 Apple 지향 메타데이터 처리가 없는 서버에서 기본 Windows 디렉터리 목록과는 다르게 Mac에 영향을 미칩니다.

터미널에서 같은 마운트된 공유를 다음과 같은 명령어로 테스트하세요. ls또는 큰 디렉터리를 먼저 탐색하지 않고 대용량 파일 하나를 복사하세요. 터미널 접근은 작동하지만 Finder가 느리면 인증보다는 메타데이터 및 디렉터리 열거 문제를 해결하세요.

느린 공유는 실패한 공유와 다릅니다.

인증 실패와 전송 속도 문제를 하나의 진단으로 결합하지 마세요. 공유를 마운트할 수 없는 Mac과 성공적으로 마운트하지만 쓰기가 느린 Mac은 다른 문제입니다.

한 Unraid 커뮤니티 사례에서 읽기는 약 180 MB/s에 도달했지만 쓰기는 약 2 MB/s로 떨어졌습니다. 로컬 디스크와 네트워크 테스트는 훨씬 빨랐습니다. 이는 증상 패턴으로 유용하지만 서명이 보편적 원인임을 증명하지는 않습니다. 저장소 구성, 캐시 동작, 소형 파일, 클라이언트 인터페이스 및 Samba 설정도 유사한 비대칭을 일으킬 수 있습니다.

네트워크 처리량, 대용량 파일 읽기, 대용량 파일 쓰기, 다수의 소형 파일 작업을 별도로 측정하세요. 실제로 느린 테스트를 확인한 후에만 SMB 성능 설정을 조정하세요.

Docker 기반 Samba는 사용자 및 볼륨 매핑 문제를 추가합니다.

Samba 컨테이너는 Windows 연결은 허용하지만 macOS는 거부할 수 있습니다. 이는 두 클라이언트가 동일한 신원을 제시하지 않기 때문입니다. 컨테이너가 포트 445를 올바르게 공개하더라도 마운트된 볼륨의 소유권이나 ACL이 호환되지 않을 수 있습니다.

컨테이너 내부의 Samba 계정, 마운트된 저장소에 사용된 호스트 UID 및 GID, 볼륨의 읽기/쓰기 권한, 공개된 포트 및 실제 설정을 확인하세요. smb.confMac이 연결을 시도하는 동안 컨테이너 로그를 검토하세요.

요청이 컨테이너에 도달하고 인증이 성공하면 Docker 네트워킹 변경을 중단하세요. 사용자 매핑, 공유 구성, 파일 시스템 소유권 및 Apple 메타데이터 지원에 집중하세요.

클라이언트 측 SMB 조정은 마지막 단계로 처리하세요

온라인 수정은 종종 긴 /etc/nsmb.conf 서명을 비활성화하거나 디렉터리 캐싱을 변경하거나 프로토콜을 강제하거나 다중 채널 동작을 수정하는 파일입니다. 이러한 설정을 한꺼번에 복사하면 어떤 변경이 영향을 미쳤는지 알 수 없습니다.

디렉터리 캐싱 및 유선 다중 채널 동작과 관련된 커뮤니티 테스트 변경 사항은 특정 macOS, 네트워크 및 Unraid 조합에 도움이 될 수 있습니다. 동일한 논의에는 보안을 저하시킬 수 있는 옵션과 상충되는 결과도 포함되어 있으므로 보편적인 구성보다는 실험적 문제 해결로 간주해야 합니다.

편집 전 nsmb.conf현재 상태를 저장하고 한 번에 하나의 매개변수를 변경합니다. 각 변경 후 동일한 폴더와 파일 전송을 다시 테스트합니다. 보안 위험을 이해하고 공유가 신뢰할 수 있는 네트워크로 제한되지 않는 한 속도 향상만을 위해 서명을 비활성화하지 마십시오.

계층화된 문제 해결 순서 따르기

가장 효과적인 절차는 정확한 대상에서 시작하여 점점 더 구체적인 클라이언트 동작으로 이동합니다. Samba, 키체인, DNS, 서명 및 Finder 설정을 동시에 편집하지 마십시오.

작동하는 Windows 경로에서 시작하여 테스트합니다 smb://IP/share macOS에서 포트 445를 확인합니다. 그런 다음 저장된 자격 증명을 지우고 계정 신원을 확인하며 SMB2/3 지원을 점검합니다. 이후 서명, 공유 권한, 파일 시스템 ACL, Samba Apple 확장 및 Finder 성능을 검사합니다.

이 순서는 각 테스트의 증거를 보존합니다. IP 대 호스트 이름 결과는 검색 문제를 식별하고, 로그인 프롬프트는 연결 가능한 SMB 서비스를 나타내며, 마운트되었지만 읽기 전용인 공유는 권한 문제를 나타내고, 작동하는 터미널 세션과 느린 Finder 창은 클라이언트 측 탐색 동작을 식별합니다.

최종 요점

SMB가 Windows에서는 작동하지만 macOS에서는 실패할 때, 모든 서버 설정이 올바르다는 증거보다는 Windows 연결을 참조로 사용하세요. 두 클라이언트는 서로 다른 주소, 사용자 이름, 캐시된 자격 증명, 프로토콜 기능 또는 권한을 사용할 수 있습니다.

정확한 smb://IP/share 경로. IP가 작동하지만 호스트 이름이 실패하면 검색 문제를 해결하세요. 로그인에 실패하면 키체인 자격 증명을 삭제하고 서버 계정을 확인하세요. 인증은 성공하지만 파일 접근이 안 되면 공유 권한과 파일 시스템 ACL을 점검하세요. 공유는 마운트되지만 Finder가 느리면 메타데이터, Samba Apple 확장 및 성능 측정 테스트로 넘어가세요.

서명 또는 협상 검사를 비활성화하는 클라이언트 측 옵션은 최후의 수단으로 남겨두어야 합니다. 최신 SMB2/3 서버, 명확한 계정 매핑, 올바른 권한, 그리고 의도적인 macOS 메타데이터 지원이 설명되지 않은 구성 불일치를 수용하기 위해 보안을 약화시키는 것보다 더 신뢰할 수 있는 해결책을 제공합니다.

자주 묻는 질문

Windows는 내 SMB 서버를 볼 수 있는데 Finder는 왜 볼 수 없나요?

Windows와 macOS는 서로 다른 검색 방법을 사용할 수 있습니다. 정확한 서버 IP와 공유 경로를 사용해 보세요. smb://192.168.x.x/share. 만약 이것이 작동한다면 문제는 SMB 자체가 아니라 호스트 이름 해석 또는 검색입니다.

Windows에서는 작동하는 비밀번호를 Mac이 계속 거부하는 이유는 무엇인가요?

Mac이 키체인에서 이전 비밀번호를 재사용하거나 서버 계정 대신 로컬 macOS 사용자 이름을 보낼 수 있습니다. 저장된 SMB 자격 증명을 제거하고 파일 서버에 정의된 계정으로 다시 연결하세요.

macOS에서 SMB 서명을 비활성화해야 하나요?

첫 번째 해결책으로는 권장하지 않습니다. 서명 비활성화는 메시지 무결성 보호를 줄이고 오래되었거나 일관성 없는 서버 구성을 숨길 수 있습니다. 먼저 SMB2/3 지원, 자격 증명, 권한 및 서버 서명 정책을 확인하세요.

Mac이 공유를 마운트할 수 있는데 파일을 생성하거나 편집할 수 없는 이유는 무엇인가요?

연결과 인증은 성공했지만 사용자가 SMB 공유 구성 또는 기본 NTFS/POSIX 파일 시스템 권한에서 쓰기 권한이 없을 수 있습니다.

Windows 파일 탐색기는 빠른데 왜 Finder는 느릴까요?

Finder는 추가 메타데이터를 요청하며 대용량 디렉터리를 나열하는 데 더 많은 시간을 소비할 수 있습니다. 보안 설정을 변경하기 전에 직접 대용량 파일 전송을 테스트하고 Finder와 터미널을 비교하세요.