Azure Files 연결 및 액세스 문제 해결(SMB)

아티클
10/15/2024

이 문서에서는 Windows 또는 Linux 클라이언트에서 SMB(서버 메시지 블록) Azure 파일 공유에 연결하고 액세스하려고 할 때 발생할 수 있는 일반적인 문제를 나열합니다. 또한 이러한 문제의 가능한 원인과 해결 방법을 제공합니다.

참고 항목

이 문서가 도움이 되었나요? 귀하의 입력은 우리에게 중요합니다. 이 페이지의 피드백 단추를 사용하여 이 문서가 얼마나 잘 작동했는지 또는 어떻게 개선할 수 있는지 알려주세요.

Important

이 문서는 SMB 공유에만 적용됩니다. NFS(네트워크 파일 시스템) 공유에 대한 자세한 내용은 Azure NFS 파일 공유 문제 해결을 참조하세요.

적용 대상

파일 공유 유형	SMB	NFS
표준 파일 공유(GPv2), LRS/ZRS
표준 파일 공유(GPv2), GRS/GZRS
프리미엄 파일 공유(FileStorage), LRS/ZRS

Azure 파일 공유에 액세스하는 데 사용하는 클라이언트 운영 체제에 따라 Windows 또는 Linux 탭을 선택합니다.

Windows
Linux

Windows에서 Azure Files 공유에 연결하려고 하면 다음 오류 메시지가 표시될 수 있습니다.

Azure 파일 공유를 탑재할 때 오류 5 발생

시스템 오류 5가 발생했습니다. 액세스가 거부되었습니다.

원인 1: 암호화되지 않은 통신 채널

보안상 이유로, 통신 채널이 암호화되지 않고 Azure Files 공유가 있는 같은 데이터 센터에서 연결 시도가 이루어지지 않을 경우 Azure Files 공유에 대한 연결이 차단됩니다. 스토리지 계정에서 보안 전송 필요 설정을 사용하도록 설정한 경우에도 동일한 데이터 센터 내의 암호화되지 않은 연결이 차단됩니다. 최종 사용자의 클라이언트 OS가 SMB 암호화를 지원하는 경우에만 암호화된 통신 채널이 제공됩니다.

Windows 8, Windows Server 2012 이상 버전의 각 시스템은 SMB 3을 포함하는 요청을 협상합니다.암호화를 지원하는 x.

원인 1의 해결 방법

SMB 암호화를 지원하는 클라이언트에서 연결합니다(Windows 8/Windows Server 2012 이상).
Azure Files 공유에 사용되는 Azure 스토리지 계정과 동일한 데이터 센터의 VM(가상 머신)에서 연결합니다.
클라이언트가 SMB 암호화를 지원하지 않는 경우 스토리지 계정에서 보안 전송 필요 설정이 사용하지 않도록 설정되었는지 확인합니다.

원인 2: 가상 네트워크 또는 방화벽 규칙이 스토리지 계정에서 사용하도록 설정됨

VNET(가상 네트워크) 및 방화벽 규칙이 스토리지 계정에 구성되는 경우, 클라이언트 IP 주소 또는 가상 네트워크가 허용 목록에 없으면 네트워크 트래픽이 거부됩니다.

원인 2의 해결 방법

가상 네트워크 및 방화벽 규칙이 스토리지 계정에 제대로 구성되어 있는지 확인합니다. 가상 네트워크 또는 방화벽 규칙에서 문제가 발생하는지 테스트하려면 일시적으로 스토리지 계정의 설정을 모든 네트워크에서 액세스 허용으로 변경합니다. 자세한 내용은 Azure Storage 방화벽 및 가상 네트워크 구성을 참조하세요.

사용자가 ID 기반 인증을 사용하여 Azure 파일 공유에 액세스하는 경우 공유 수준 권한이 올바르지 않으면 "액세스 거부됨" 오류와 함께 파일 공유에 대한 액세스가 실패합니다.

원인 3의 해결 방법

공유 수준 권한이 올바르게 구성되었는지 확인합니다. 공유 수준 권한 할당을 참조 하세요. 공유 수준 권한 할당은 Microsoft Entra Connect 동기화 또는 Microsoft Entra Connect 클라우드 동기화를 사용하여 AD DS에서 Microsoft Entra ID로 동기화된 그룹 및 사용자에 대해 지원됩니다. 공유 수준 권한이 할당된 그룹 및 사용자가 지원되지 않는 "클라우드 전용" 그룹이 아닌지 확인합니다.

Azure 파일 공유를 탑재 또는 탑재 해제하는 경우 오류 53, 오류 67 또는 오류 87 발생

온-프레미스 또는 다른 데이터 센터에서 파일 공유를 탑재하려고 하면 다음 오류가 발생할 수 있습니다.

시스템 오류 53이 발생했습니다. 네트워크 경로를 찾을 수 없습니다.
시스템 오류 67이 발생했습니다. 네트워크 이름을 찾을 수 없습니다.
시스템 오류 87이 발생했습니다. 매개 변수가 올바르지 않습니다.

원인 1: 포트 445 차단

시스템 오류 53 또는 시스템 오류 67은 Azure Files 데이터 센터에 대한 포트 445 아웃바운드 통신이 차단될 경우 발생할 수 있습니다. 포트 445에서 시작되는 액세스를 허용하거나 거부하는 ISP에 대한 요약을 확인하려면 TechNet으로 이동합니다.

방화벽 또는 ISP가 포트 445를 차단하고 있는지 확인하려면 AzFileDiagnostics 도구 또는 Test-NetConnection cmdlet을 사용합니다.

Test-NetConnectioncmdlet을 사용하려면 Azure PowerShell 모듈을 설치해야 합니다. 자세한 내용은 Azure PowerShell 모듈 설치를 참조하세요. 잊지 말고 <your-storage-account-name> 및 <your-resource-group-name>을 스토리지 계정과 관련된 이름으로 바꿔야 합니다.

$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"

# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445

연결이 성공하면 다음이 출력됩니다.

ComputerName     : <your-storage-account-name>
RemoteAddress    : <storage-account-ip-address>
RemotePort       : 445
InterfaceAlias   : <your-network-interface>
SourceAddress    : <your-ip-address>
TcpTestSucceeded : True

참고 항목

이 명령은 스토리지 계정의 현재 IP 주소를 반환합니다. 이 IP 주소가 동일하게 유지된다는 보장이 없으며, 언제든지 변경될 수 있습니다. 이 IP 주소를 스크립트로 또는 방화벽 구성으로 하드 코딩하지 마세요.

원인 1의 해결 방법

해결 방법 1 - Azure 파일 동기화를 QUIC 엔드포인트로 사용 포트 445가 차단된 클라이언트에서 Azure Files 액세스하기 위한 해결 방법으로 Azure 파일 동기화를 사용할 수 있습니다. Azure Files는 QUIC를 통해 SMB를 직접 지원하지는 않지만 Windows Server 2022 Azure Edition은 QUIC 프로토콜을 지원합니다. Azure 파일 동기화를 사용하여 Windows Server 2022 Azure Edition VM에서 Azure 파일 공유의 간단한 캐시를 만들 수 있습니다. 이 구성은 포트 445 대신 HTTPS를 지원하기 위해 널리 열려 있는 아웃바운드 포트 443을 사용합니다. 이 옵션에 대한 자세한 내용은 Azure 파일 동기화를 사용하는 QUIC를 통한 SMB를 참조하세요.

솔루션 2 - VPN 또는 ExpressRoute 를 사용하여 온-프레미스에서 Azure Storage 계정으로 VPN(가상 사설망) 또는 ExpressRoute를 설정하고, 프라이빗 엔드포인트를 사용하여 내부 네트워크에 Azure Files를 노출하면 트래픽이 인터넷을 통한 것이 아니라 보안 터널을 통과합니다. 지침에 따라 Windows에서 Azure Files에 액세스하도록 VPN 을 설치합니다.

해결 방법 3 - ISP/IT 관리자의 도움을 받아 포트 445 차단 해제 IT 부서 또는 ISP와 협력하여 Azure IP 범위로 아웃바운드되는 포트 445를 엽니다.

솔루션 4 - Storage Explorer 또는 PowerShell Azure Files와 같은 REST API 기반 도구를 사용하여 SMB 외에 REST도 지원합니다. REST 액세스는 포트 443(표준 TCP)을 통해 작동합니다. 다양한 UI 환경을 가능하게 하는 REST API를 사용하여 작성된 다양한 도구가 있습니다. Storage Explorer가 그중 하나입니다. Storage Explorer를 다운로드하여 설치하고 Azure Files에서 지원하는 파일 공유에 연결합니다. REST API를 사용하는 PowerShell을 사용할 수도 있습니다.

원인 2: NTLMv1 사용

클라이언트에서 NTLMv1 통신이 사용될 경우 시스템 오류 53 또는 시스템 오류 87이 발생할 수 있습니다. Azure Files는 NTLMv2 인증만 지원합니다. NTLMv1을 사용하도록 설정하면 클라이언트 보안이 약화됩니다. 따라서 Azure Files에 대한 통신이 차단됩니다.

이것이 오류의 원인인지 확인하려면 다음 레지스트리 하위 키가 3 미만의 값으로 설정되어 있지 않은지 확인합니다.

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

자세한 내용은 TechNet에서 LmCompatibilityLevel 항목을 참조하세요.

원인 2의 해결 방법

다음 레지스트리 하위 키에서 LmCompatibilityLevel 값을 기본값인 3으로 되돌립니다.

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

오류 코드 0x800704b3 실패

Azure 파일 공유를 탑재하려고 하면 다음 오류가 발생합니다.

오류 코드: 0x800704b3
기호 이름: ERROR_NO_NET_OR_BAD_PATH
오류 설명: 네트워크 경로가 잘못 입력되었거나, 존재하지 않거나, 네트워크 공급자를 현재 사용할 수 없습니다. 경로를 다시 입력하거나 네트워크 관리자에게 문의하세요.

원인

이 오류는 해당 네트워크 서비스에 명시적으로 의존하는 모든 서비스가 시작되지 않으므로 핵심 Windows 네트워크 관련 서비스를 사용하지 않도록 설정한 경우에 발생할 수 있습니다.

솔루션

다음 서비스 중 Windows VM에서 중지된 상태인지 확인합니다.

네트워크 연결
네트워크 목록 서비스
네트워크 위치 인식
네트워크 저장소 인터페이스 서비스
DHCP 클라이언트
TCP/IP NetBIOS 도우미
워크스테이션

있는 경우 서비스를 시작하고 Azure 파일 공유 탑재를 다시 시도합니다.

애플리케이션 또는 서비스가 탑재된 Azure Files 드라이브에 액세스할 수 없습니다.

원인

드라이브는 사용자별로 탑재됩니다. 애플리케이션 또는 서비스가 드라이브를 탑재한 계정이 아닌 다른 사용자 계정으로 실행되는 경우 애플리케이션에는 드라이브가 표시되지 않습니다.

솔루션

다음 솔루션 중 하나를 사용하세요.

애플리케이션을 포함하는 동일한 사용자 계정에서 드라이브를 탑재합니다. PsExec와 같은 도구를 사용할 수 있습니다.
net use 명령의 사용자 이름 및 암호 매개 변수에 스토리지 계정 이름 및 키를 전달합니다.
cmdkey 명령을 사용하여 자격 증명 관리자에 자격 증명을 추가합니다. 대화형 로그인 또는 runas를 통해 서비스 계정 컨텍스트의 명령줄에서 이 작업을 수행합니다.
```
cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>
```
매핑된 드라이브 문자를 사용하지 않고 직접 공유를 매핑합니다. 일부 애플리케이션은 드라이브 문자에 제대로 다시 연결되지 않을 수 있으므로 전체 UNC 경로를 사용하는 것이 더 안정적일 수 있습니다.

net use * \\storage-account-name.file.core.windows.net\share

다음과 같은 지침을 따르고 시스템/네트워크 서비스 계정에 net use를 실행하면 다음과 같은 오류 메시지가 표시될 수 있습니다. "시스템 오류 1312가 발생했습니다. 지정된 로그온 세션이 없습니다. 이미 종료되었을 수 있습니다." 이 오류가 표시되면 전달된 net use 사용자 이름에 도메인 정보(예: [storage account name].file.core.windows.net)가 포함되어 있는지 확인합니다.

"내 컴퓨터" 또는 "이 PC"에 드라이브 문자를 가진 폴더가 없습니다.

net use 명령을 사용하여 관리자 권한으로 Azure 파일 공유를 매핑하는 경우 공유가 누락될 수 있습니다.

원인

기본적으로 Windows File Explorer는 관리자 권한으로 실행되지 않습니다. 관리자 명령 프롬프트에서 net use를 실행할 경우 네트워크 드라이브를 관리자 권한으로 매핑합니다. 매핑된 드라이브는 사용자 중심이므로 다른 사용자 계정으로 탑재될 경우 로그인된 사용자 계정에 드라이브가 표시되지 않습니다.

솔루션

비관리자 명령줄에서 공유를 탑재하세요. 또는 이 TechNet 항목에 따라 레지스트리 값을 구성할 EnableLinkedConnections 수 있습니다.

내 스토리지 계정에 슬래시(/)가 포함되는 경우 net use 명령이 실패합니다.

원인

net use 명령은 슬래시(/)를 명령줄 옵션으로 해석합니다. 사용자 계정 이름이 슬래시로 시작되면 드라이브 매핑에 실패합니다.

솔루션

다음 단계 중 하나를 사용하여 문제를 해결할 수 있습니다.

다음 PowerShell 명령을 실행합니다.
```
New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"
```
배치 파일에서 다음과 같은 방식으로 명령을 실행할 수 있습니다.

Echo new-smbMapping ... | powershell -command –
슬래시(/)가 첫 번째 문자가 아닐 경우 키 주위에 큰따옴표를 배치하여 이 문제를 해결합니다. 슬래시(/)가 첫 번째 문자일 경우 대화형 모드를 사용하여 암호를 개별적으로 입력하거나 키를 다시 생성하여 슬래시(/) 문자로 시작되지 않는 키를 얻습니다.

"네트워크 리소스 유형이 올바르지 않음" 오류로 New-PSDrive 명령 실패

원인

파일 공유에 액세스할 수 없는 경우 이 오류 메시지가 표시될 수 있습니다. 예를 들어 포트 445가 차단되거나 DNS 확인 문제가 있습니다.

솔루션

포트 445가 열려 있는지 확인하고 DNS 확인 및 파일 공유에 대한 연결을 확인합니다.

이 문제에 대한 일반적인 원인은 다음과 같습니다.

오래된 SMB 클라이언트에서 Linux 배포를 사용하고 있습니다. 호환되는 클라이언트가 있는 Azure에서 사용할 수 있는 일반적인 Linux 배포에 대한 자세한 내용은 Linux에서 Azure Files 사용을 참조하세요.
SMB 유틸리티(cifs-utils)가 클라이언트에 설치되어 있지 않습니다.
최소 SMB 버전 2.1은 클라이언트에서 사용할 수 없습니다.
SMB 3.x 암호화는 클라이언트에서 지원되지 않습니다. 위의 표에서는 암호화를 사용하여 온-프레미스 및 지역 간 탑재를 지원하는 Linux 배포 목록을 제공합니다. 기타 배포에는 커널 4.11 이상 버전이 필요합니다.
Azure VM에서 Azure 파일 공유에 연결하려고 하며, VM이 스토리지 계정과 동일한 지역에 있지 않습니다.
스토리지 계정에서 보안 전송 필요 설정을 사용하도록 설정한 경우 Azure Files에서는 암호화 기능이 포함된 SMB 3.x를 사용하는 연결만 허용합니다.

솔루션

이 문제를 해결하려면 Linux에서 Azure Files 탑재 오류에 대한 문제 해결 도구를 사용합니다. 이 도구는 다음과 같은 작업을 수행합니다.

클라이언트 실행 환경의 유효성을 검사하는 데 도움이 됩니다.
Azure Files에 대한 액세스 실패를 일으키는 호환되지 않는 클라이언트 구성을 검색합니다.
자체 수정에 대한 규범적인 지침을 제공합니다.
진단 추적을 수집합니다.

Azure 파일 공유를 탑재하면 "탑재 오류(13): 사용 권한 거부됨" 오류 발생

원인 1: 암호화되지 않은 통신 채널

보안상의 이유로 통신 채널이 암호화되지 않고 Azure 파일 공유가 있는 동일한 데이터 센터에서 연결 시도가 이루어지지 않으면 Azure 파일 공유에 대한 연결이 차단됩니다. 스토리지 계정에서 보안 전송 필요 설정을 사용하도록 설정한 경우에도 동일한 데이터 센터 내의 암호화되지 않은 연결을 차단할 수 있습니다. 암호화된 통신 채널은 사용자의 클라이언트 OS가 SMB 암호화를 지원하는 경우에만 제공됩니다.

자세한 내용은 Linux 및 cifs-utils 패키지와 함께 Azure 파일 공유를 탑재하기 위한 필수 조건을 참조하세요.

원인 1의 해결 방법

SMB 암호화를 지원하는 클라이언트에서 연결하거나 Azure 파일 공유에 사용되는 Azure Storage 계정과 동일한 데이터 센터의 가상 머신에서 연결합니다.
클라이언트가 SMB 암호화를 지원하지 않는 경우 스토리지 계정에서 보안 전송 필요 설정이 사용하지 않도록 설정되었는지 확인합니다.

원인 2: 가상 네트워크 또는 방화벽 규칙이 스토리지 계정에서 사용하도록 설정됨

가상 네트워크(VNET) 및 방화벽 규칙이 스토리지 계정에 구성된 경우, 클라이언트 IP 주소 또는 가상 네트워크에 액세스가 허용되지 않았다면 네트워크 트래픽이 거부됩니다.

원인 2의 해결 방법

VNET 및 방화벽 규칙이 스토리지 계정에 올바르게 구성되고 포트 445가 허용 목록에 있는지 확인합니다. 가상 네트워크 또는 방화벽 규칙으로 인해 문제가 발생하는지 테스트하려면 스토리지 계정의 설정을 일시적으로 변경하여 모든 네트워크의 액세스를 허용할 수 있습니다. 자세한 내용은 Azure Storage 방화벽 및 가상 네트워크 구성을 참조하세요.

원인 3: SMB 클라이언트가 NTLMv1을 사용하도록 구성됨

Azure Files는 SMB 파일 공유에 대해 NTLMv2 및 Kerberos만 지원합니다. 커널 4.4 이상 버전은 기본적으로 NTLMv2를 사용하도록 설정하고 LANMAN을 사용하지 않도록 설정합니다. 기본 구성에서 NTLMv1은 협상 전용 옵션으로 유지됩니다. 자세한 내용은 OS 설명서를 참조하세요.

원인 3의 해결 방법

SMB 탑재 명령이 옵션을 통해 sec 기본 NTLMv2 인증을 재정의하지 않는지 확인합니다. 이 sec 옵션은 SMB Azure 파일 공유에 연결할 때 사용하거나 ntlmi 사용하지 ntlm 않아야 합니다. /etc/samba/smb.conf에서 전역 옵션을 설정하는 경우 NTLMv2를 사용하지 않도록 설정하지 않도록 설정해야 합니다.

원인 4: 정책을 통해 스토리지 계정 키 액세스가 비활성화되거나 허용되지 않음

스토리지 계정에 대해 스토리지 계정 키 액세스를 사용하지 않도록 설정하거나 허용하지 않으면 SAS 토큰 및 액세스 키가 작동하지 않습니다.

원인 4에 대한 해결 방법

ID 기반 인증을 사용합니다. 파일 공유는 온-프레미스 Active Directory AD DS(Domain Servies) 또는 Microsoft Entra Domain Services 도메인에 조인되어야 하며 Linux 클라이언트는 Kerberos 인증을 사용하도록 구성되어야 합니다.

SMB 3.x를 사용하여 Azure Files를 탑재할 때 “Mount 오류(115): 작업이 진행되고 있습니다”

원인

일부 Linux 배포는 아직 SMB 3.x의 암호화 기능을 지원하지 않습니다. 사용자는 SMB 3.x를 사용하여 Azure Files를 탑재할 경우 기능 누락으로 인해 “115” 오류 메시지를 수신할 수 있습니다. 전체 암호화가 포함된 SMB 3.x는 최신 버전의 Linux 배포판에서만 지원됩니다.

솔루션

Linux용 SMB 3.x의 암호화 기능은 4.11 커널에서 도입되었습니다. 이 기능을 사용하면 온-프레미스 또는 다른 Azure 지역에서 Azure 파일 공유를 탑재할 수 있습니다. 일부 Linux 배포판은 4.11 커널에서 유지 관리되는 이전 버전의 Linux 커널로의 변경 내용을 백포트할 수 있습니다. Linux 버전이 암호화와 함께 SMB 3.x를 지원하는지 확인하려면 Linux에서 Azure Files 사용을 참조하세요.

Linux SMB 클라이언트가 암호화를 지원하지 않는 경우 파일 공유와 같은 Azure 데이터 센터의 Linux VM에서 SMB 2.1을 사용하여 Azure Files를 탑재합니다. 스토리지 계정에서 보안 전송 필요 설정을 사용하지 않도록 설정했는지 확인합니다.

다시 연결 시간 제한으로 인한 "탑재 오류(112): 호스트가 중단됨"

Linux 클라이언트에서 클라이언트가 장시간 유휴 상태일 경우 "112" 탑재 오류가 발생합니다. 유휴 시간이 연장되면 클라이언트의 연결이 끊어지고 연결 시간이 초과됩니다.

원인

다음과 같은 이유로 연결이 유휴 상태일 수 있습니다.

기본 "소프트" 탑재 옵션을 사용할 때 서버에 대한 TCP 연결을 다시 설정하지 못하게 하는 네트워크 통신 오류입니다.
이전 커널에 없는 최근 다시 연결 수정

솔루션

Linux 커널의 이러한 재연결 문제는 현재 다음 변경의 일부로 수정되었습니다.

그러나 이러한 변경 내용은 아직 모든 Linux 배포판에 이식되지 않을 수 있습니다. 인기 있는 Linux 배포판을 사용하는 경우 Linux에서 Azure Files 사용을 확인하여 필요한 커널 변경 내용이 있는 배포 버전을 확인할 수 있습니다.

해결 방법

하드 탑재를 지정하여 이 문제를 해결할 수 있습니다. 하드 탑재를 사용하면 클라이언트는 연결이 설정될 때까지 또는 연결이 명시적으로 중단될 때까지 대기해야 합니다. 하드 탑재는 네트워크 시간 제한으로 인한 오류를 방지하는 데 사용할 수 있습니다. 그러나 이 해결 방법은 무한 대기를 일으킬 수 있습니다. 필요에 따라 연결을 중지할 준비가 되어 있어야 합니다.

최신 커널 버전으로 업그레이드할 수 없는 경우 매 30초 이하 간격으로 쓰는 Azure 파일 공유에 파일을 보관하여 이 문제를 해결할 수 있습니다. 이 작업은 만든 또는 수정된 날짜를 파일에 다시 쓰는 등의 쓰기 작업이어야 합니다. 그렇지 않으면 캐시된 결과를 얻을 수 있고 작업이 재연결을 트리거하지 않을 수 있습니다.

고객이 시작한 장애 조치(failover) 후 "사용자 이름 또는 암호가 잘못되었습니다." 오류

지역 중복 스토리지 계정이 있는 고객이 시작한 장애 조치(failover) 시나리오에서는 장애 조치(failover) 시 파일 핸들 및 임대가 유지되지 않습니다. 클라이언트는 파일 공유를 분리하고 다시 탑재해야 합니다.

Azure 파일 공유에 액세스하거나 삭제하려고 할 때 "액세스 권한 없음" 오류 발생

Azure Portal을 사용하여 Azure 파일 공유에 액세스하거나 삭제하려고 할 때 다음 오류가 발생할 수 있습니다.

액세스 없음 오류 코드: 403

원인 1: 가상 네트워크 또는 방화벽 규칙이 스토리지 계정에서 사용하도록 설정됨

원인 1의 해결 방법

원인 2: 사용자 계정에 스토리지 계정에 대한 액세스 권한이 없음

원인 2의 해결 방법

Azure 파일 공유가 있는 스토리지 계정으로 이동하고, 액세스 제어(IAM)를 선택하고, 사용자 계정에 스토리지 계정에 대한 액세스 권한이 있는지 확인합니다. 자세한 내용은 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 스토리지 계정을 보호하는 방법을 참조하세요.

파일 잠금 및 임대

Azure 파일 공유 또는 스냅샷을 수정하거나 삭제할 수 없는 경우 이는 파일 잠금 또는 임대 때문일 수 있습니다. Azure Files는 Azure 파일 공유 및 공유 스냅샷을 실수로 수정 또는 삭제하는 것을 방지하기 위해 두 가지 방법을 제공합니다.

스토리지 계정 리소스 잠금: 스토리지 계정을 포함한 모든 Azure 리소스는 리소스 잠금을 지원합니다. 관리자 또는 Azure Backup과 같은 서비스에서 스토리지 계정에 잠금을 배치할 수 있습니다. 리소스 잠금의 두 가지 변형이 있습니다. 즉, 스토리지 계정 및 해당 리소스에 대한 모든 수정을 방지하는 수정과 스토리지 계정 및 해당 리소스의 삭제만 방지하는 삭제가 있습니다. Microsoft.Storage 리소스 공급자를 통해 공유를 수정하거나 삭제하면 Azure 파일 공유 및 공유 스냅샷에 리소스 잠금이 적용됩니다. 대부분의 포털 작업, 이름(예: )이 있는 Azure Files Rm 용 Azure PowerShell cmdlet 및 명령 그룹의 Azure CLI 명령share-rm(예az storage share-rm list: 리소스 공급자)을 사용합니다Microsoft.Storage. Get-AzRmStorageShare Storage Explorer, 이름에 없는 Rm 레거시 Azure Files PowerShell 관리 cmdlet( 예 Get-AzStorageShare: ) 및 명령 그룹의 레거시 Azure Files CLI 명령 share (예 az storage share list: )과 같은 일부 도구 및 유틸리티는 리소스 공급자 및 리소스 잠금을 우회 Microsoft.Storage 하는 FileREST API에서 레거시 API를 사용합니다. FileREST API에 노출된 레거시 관리 API에 대한 자세한 내용은 Azure Files의 컨트롤 플레인을 참조하세요.
공유/공유 스냅샷 임대: 공유 임대는 Azure 파일 공유 및 파일 공유 스냅샷에 대한 일종의 독점 잠금입니다. 스크립트 또는 Azure Backup과 같은 부가 가치 서비스를 통해 API를 호출하여 관리자가 개별 Azure 파일 공유 또는 파일 공유 스냅샷에 임대를 배치할 수 있습니다. Azure 파일 공유 또는 파일 공유 스냅샷에 임대를 설정하는 경우 임대 ID를 통해 파일 공유/공유 스냅샷을 수정하거나 삭제할 수 있습니다. 관리자는 임대 ID가 필요한 수정 작업 전에 임대를 해제하거나 임대 ID가 필요하지 않은 임대를 해제할 수도 있습니다. 공유 임대에 관한 자세한 내용은 공유 임대를 참조하세요.

리소스 잠금 및 임대는 스토리지 계정/Azure 파일 공유에서 의도한 관리자 작업을 방해할 수 있기 때문에 Azure Backup과 같은 부가 가치 서비스에 의해 수동으로 또는 자동으로 리소스에 배치되었을 수 있는 리소스 잠금/임대를 제거할 수 있습니다. 다음 스크립트는 모든 리소스 잠금 및 임대를 제거합니다. <resource-group> 및 <storage-account>를 사용자 환경에 적합한 값으로 바꿔야 합니다.

다음 스크립트를 실행하기 전에 Azure Storage PowerShell 모듈의 최신 버전을 설치해야 합니다.

Important

Azure Files 리소스에서 리소스 잠금 및 공유/공유 스냅샷 임대를 취하는 부가 가치 서비스는 주기적으로 잠금 및 임대를 다시 적용할 수 있습니다. 부가 가치 서비스로 잠긴 리소스를 수정하거나 삭제하면 Azure Backup에서 관리되는 공유 스냅샷 삭제와 같은 이러한 서비스의 정기적인 작업에 영향을 줄 수 있습니다.

# Parameters for storage account resource
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName

# Remove resource locks
Get-AzResourceLock `
        -ResourceType "Microsoft.Storage/storageAccounts" `
        -ResourceGroupName $storageAccount.ResourceGroupName `
        -ResourceName $storageAccount.StorageAccountName | `
    Remove-AzResourceLock -Force | `
    Out-Null

# Remove share and share snapshot leases
Get-AzStorageShare -Context $storageAccount.Context | `
    Where-Object { $_.Name -eq $fileShareName } | `
    ForEach-Object {
        try {
            $leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClient)
            $leaseClient.Break() | Out-Null
        } catch { }
    }

파일 또는 디렉터리를 수정, 이동/이름 바꾸기 또는 삭제할 수 없음

Azure 파일 공유에 액세스하는 데 사용하는 클라이언트 운영 체제에 따라 Windows 또는 Linux 탭을 선택합니다.

Windows
Linux

Windows에서는 다음과 같은 오류가 표시될 수 있습니다.

연결 없는 파일 핸들 또는 임대

파일 공유의 주요 목적 중 하나는 여러 사용자 및 애플리케이션이 동시에 공유 파일 및 디렉터리와 상호 작용할 수 있다는 것입니다. 이러한 상호 작용을 지원하기 위해 파일 공유에는 파일 및 디렉터리에 대한 액세스를 중재하는 방법이 여러 개 있습니다.

SMB를 통해 탑재된 Azure 파일 공유에서 파일을 열면 애플리케이션/운영 체제가 파일에 대한 참조인 파일 핸들을 요청합니다. 무엇보다도 애플리케이션은 파일 핸들을 요청할 때 파일 공유 모드를 지정합니다. 이 모드는 Azure Files에 의해 적용되는 파일에 대한 액세스의 독점 수준을 지정합니다.

None: 단독으로 액세스할 수 있습니다.
Read: 파일을 연 동안 다른 사용자가 읽을 수 있습니다.
Write: 파일을 연 동안 다른 사용자가 쓸 수 있습니다.
ReadWrite: Read 및 Write 공유 모드의 조합입니다.
Delete: 파일을 연 동안 다른 사용자가 삭제할 수 있습니다.

상태 비저장 프로토콜인 FileREST 프로토콜에는 파일 핸들 개념이 없지만 스크립트, 애플리케이션 또는 서비스에서 사용할 수 있는 파일 및 폴더에 대한 액세스를 중재하는 유사한 메커니즘인 파일 임대를 제공합니다. 파일이 임대되면 None 파일 공유 모드를 사용하여 파일 핸들과 동일하게 처리됩니다.

파일 핸들과 임대가 중요한 용도로 사용되지만 파일 핸들과 임대가 분리될 수 있습니다. 이 경우 파일 수정 또는 삭제에 문제가 발생할 수 있습니다. 다음과 같은 오류 메시지가 표시될 수도 있습니다.

다른 프로세스가 파일을 사용 중이기 때문에 프로세스가 파일에 액세스할 수 없습니다.
다른 프로그램에서 이 파일이 열려 있으므로 작업을 완료할 수 없습니다.
다른 사용자의 편집 때문에 문서가 잠겨 있습니다.
지정된 리소스는 SMB 클라이언트에서 삭제되도록 표시됩니다.

해결 방법은 연결 없는 파일 핸들로 인한 문제인지 또는 임대로 인한 문제인지에 따라 다릅니다.

참고 항목

REST 임대는 파일이 삭제되거나 수정되지 않도록 애플리케이션에서 사용됩니다. 임대를 중단하기 전에 임대를 획득하는 애플리케이션을 식별해야 합니다. 그렇지 않으면 애플리케이션 동작이 중단될 수 있습니다.

원인 1

파일 핸들로 인해 파일/디렉터리가 수정되거나 삭제되지 않습니다. Get-AzStorageFileHandle PowerShell cmdlet을 사용하여 열린 핸들을 볼 수 있습니다.

모든 SMB 클라이언트가 파일/디렉터리에서 열린 핸들을 닫은 상태에서 문제가 계속 발생하는 경우에는 파일 핸들을 강제로 닫으면 됩니다.

솔루션 1

파일 핸들을 강제로 닫으려면 Close-AzStorageFileHandle PowerShell cmdlet을 사용합니다.

참고 항목

Get-AzStorageFileHandle 및 Close-AzStorageFileHandle cmdlet은 Az PowerShell 모듈 버전 2.4 이상에 포함되어 있습니다. 최신 Az PowerShell 모듈을 설치하려면 Azure PowerShell 모듈 설치를 참조하세요.

원인 2

파일 임대로 인해 파일을 수정하거나 삭제할 수 없습니다. 파일에 다음 PowerShell 명령을 사용하여 파일 임대가 있는지 확인할 수 있습니다. <resource-group>, <storage-account>, <file-share> 및 <path-to-file>을 사용자 환경에 적합한 값으로 바꿉니다.

# Set variables 
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
        -ResourceGroupName $resourceGroupName `
        -Name $storageAccountName

# Get reference to file
$file = Get-AzStorageFile `
        -Context $storageAccount.Context `
        -ShareName $fileShareName `
        -Path $fileForLease

$fileClient = $file.ShareFileClient

# Check if the file has a file lease
$fileClient.GetProperties().Value

파일에 임대가 있는 경우 반환되는 개체에 다음 속성이 포함되어야 합니다.

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

해결 방법 2

파일에서 임대를 제거하려면 임대를 해제하거나 임대를 중단할 수 있습니다. 임대를 해제하려면 임대를 만들 때 설정한 임대의 LeaseId가 필요합니다. LeaseId는 임대를 중단할 필요가 없습니다.

다음 예는 원인 2에 표시된 파일에 대한 임대를 중단하는 방법을 보여줍니다(이 예제에서는 원인 2의 PowerShell 변수를 계속 사용).

$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null

Linux에서 다음과 같은 문제가 표시될 수 있습니다.

파일 또는 디렉터리에서 핸들 열기

원인

이 문제는 일반적으로 파일 또는 디렉터리에 열린 핸들이 있는 경우에 발생합니다.

솔루션

SMB 클라이언트가 열려 있는 모든 핸들을 닫았고 문제가 계속 발생하는 경우 다음을 수행합니다.

열린 핸들을 보려면 Get-AzStorageFileHandle PowerShell cmdlet을 사용합니다.
Close-AzStorageFileHandle PowerShell cmdlet을 사용하여 열린 핸들을 닫습니다.

참고 항목

Linux에서 Azure 파일 공유 스냅샷을 탑재하려고 할 때 "탑재 오류(22): 잘못된 인수"

원인

mount 명령에 대한 snapshot 옵션이 인식된 형식으로 전달되지 않으면 mount 명령은 이 오류와 함께 실패할 수 있습니다. 확인하려면 커널 로그 메시지(dmesg)를 확인하고 dmesg는 로그 항목(예: cifs: Bad value for 'snapshot')을 표시합니다.

솔루션

올바른 형식으로 mount 명령에 대한 snapshot 옵션을 전달하고 있는지 확인합니다. mount.cifs 수동 페이지(예: man mount.cifs)를 참조하세요. 일반적인 오류는 마침표 대신 하이픈 또는 콜론을 사용하는 것과 같은 잘못된 형식으로 GMT 타임스탬프를 전달하는 것입니다. 자세한 내용은 파일 공유 스냅샷 탑재를 참조하세요.

Linux에서 Azure 파일 공유 스냅샷을 탑재하려고 할 때 "잘못된 스냅샷 토큰"

원인

스냅샷 mount 옵션을 @GMT로 시작하지만 형식이 여전히 잘못된 경우(예: 마침표 대신 하이픈 및 콜론 사용) 이 오류와 함께 mount 명령이 실패할 수 있습니다.

솔루션

GMT 타임스탬프를 올바른 형식으로 @GMT-year.month.day-hour.minutes.seconds전달하고 있는지 확인합니다. 자세한 내용은 파일 공유 스냅샷 탑재를 참조하세요.

Azure 파일 공유 스냅샷을 탑재하려고 할 때 "탑재 오류(2): 그러한 파일 또는 디렉터리가 없습니다."

원인

탑재하려는 스냅샷이 없으면 이 오류로 명령이 mount 실패할 수 있습니다. 확인하려면 커널 로그 메시지(dmesg)를 확인하고 dmesg는 다음과 같은 로그 항목을 표시합니다.

[Mon Dec 12 10:34:09 2022] CIFS: Attempting to mount \\snapshottestlinux.file.core.windows.net\snapshot-test-share1
[Mon Dec 12 10:34:09 2022] CIFS: VFS: cifs_mount failed w/return code = -2

솔루션

탑재하려는 스냅샷 있는지 확인합니다. 지정된 Azure 파일 공유에 사용 가능한 스냅샷을 나열하는 방법에 대한 자세한 내용은 파일 공유 스냅샷 탑재를 참조하세요.

너무 많은 열린 핸들로 인한 디스크 할당량 또는 네트워크 오류

Azure 파일 공유에 액세스하는 데 사용하는 클라이언트 운영 체제에 따라 Windows 또는 Linux 탭을 선택합니다.

Windows
Linux

오류 1816 - 할당량이 부족하여 이 명령을 처리할 수 없습니다.

원인

Azure 파일 공유의 파일 또는 디렉터리에 허용되는 동시 열린 핸들의 상한값에 도달하는 경우 오류 1816이 발생합니다. 자세한 내용은 Azure Files 크기 조정 목표을 참조하세요.

솔루션

일부 핸들을 닫아 동시 열린 핸들 수를 줄이고 다시 시도하세요. 자세한 내용은 Microsoft Azure Storage 성능 및 확장성 검사 목록을 참조하세요.

파일 공유, 디렉터리 또는 파일의 열린 핸들을 보려면 Get-AzStorageFileHandle PowerShell cmdlet을 사용합니다.

파일 공유, 디렉터리 또는 파일의 열린 핸들을 닫으려면 Close-AzStorageFileHandle PowerShell cmdlet을 사용합니다.

참고 항목

핸들에서 작업을 수행할 때 ERROR_UNEXP_NET_ERR(59)

원인

오랜 시간 동안 많은 수의 열린 핸들을 캐시/보류하는 경우 제한 이유로 인해 이 서버 쪽 실패가 표시될 수 있습니다. 많은 수의 핸들이 클라이언트에 의해 캐시되면 많은 핸들이 동시에 다시 연결 단계로 전환되어 서버에서 제한해야 하는 큐 정체가 발생할 수 있습니다. 재시도 논리 및 다시 연결에 대한 백 엔드의 제한은 클라이언트의 시간 제한보다 오래 걸립니다. 이 상황은 ERROR_UNEXP_NET_ERR(59)와 함께 모든 작업이 실패하면서 클라이언트가 어떤 작업에도 기존 핸들을 사용할 수 없는 것으로 나타납니다.

클라이언트 핸들이 서버에서 연결이 끊어져(예: 몇 분 동안 지속되는 네트워크 중단) 이런 오류를 일으킬 수 있는 극단적인 경우도 있습니다.

솔루션

많은 수의 핸들을 캐시하지 마세요. 핸들을 닫은 다음 다시 시도합니다. Get-AzStorageFileHandle 및 Close-AzStorageFileHandle PowerShell cmdlet을 사용하여 열린 핸들을 보거나 닫습니다.

Azure 파일 공유를 사용하여 대규모 가상 데스크톱 배포 또는 파일, 디렉터리 및/또는 루트 디렉터리에 대한 핸들을 여는 다른 워크로드에 대한 프로필 컨테이너 또는 디스크 이미지를 저장하는 경우 동시 열린 핸들에 대한 상한 값에 도달할 수 있습니다. 이 경우 추가 Azure 파일 공유를 사용하고 공유 간에 컨테이너 또는 이미지를 배포합니다.

파일을 열려고 할 때 “[사용 권한 거부됨] 디스크 할당량이 초과됨”

Linux에서는 다음과 유사한 오류 메시지가 표시될 수 있습니다.

<파일 이름> [사용 권한 거부] 디스크 할당량 초과

원인

파일 또는 디렉터리에 허용되는 동시 열린 핸들의 상한에 도달했습니다.

Azure Files는 루트 디렉터리에서 10,000개의 열린 핸들과 공유 내의 파일 및 디렉터리당 2,000개의 열린 핸들을 지원합니다.

솔루션

일부 핸들을 닫아 동시 열린 핸들 수를 줄인 다음 작업을 다시 시도합니다.

파일 공유, 디렉터리 또는 파일의 열린 핸들을 보려면 Get-AzStorageFileHandle PowerShell cmdlet을 사용합니다.

파일 공유, 디렉터리 또는 파일의 열린 핸들을 닫으려면 Close-AzStorageFileHandle PowerShell cmdlet을 사용합니다.

참고 항목

“암호화를 지원하지 않는 대상에 파일을 복사하는 중임” 오류 발생

네트워크를 통해 파일이 복사되면 파일은 원본 컴퓨터에서 암호를 해독하고, 일반 텍스트로 전송되어 대상에서 다시 암호화됩니다. 하지만 암호화된 파일을 복사하려 하는 경우 다음 오류가 발생할 수 있습니다. "암호화를 지원하지 않는 대상에 파일을 복사하고 있습니다."

원인

EFS(파일 시스템 암호화)를 사용하는 경우 이 문제가 발생할 수 있습니다. BitLocker로 암호화된 파일을 Azure Files로 복사할 수 있습니다. 하지만 Azure Files는 NTFS EFS를 지원하지 않습니다.

해결 방법

파일을 네트워크로 복사하려면 먼저 파일을 암호 해독해야 합니다. 다음 방법 중 하나를 사용하십시오.

copy /d 명령을 사용합니다. 암호화된 파일을 대상에서 암호 해독된 파일로 저장할 수 있습니다.
다음 레지스트리 키를 설정합니다.
- Path = HKLM\Software\Policies\Microsoft\Windows\System
- Value type = DWORD
- Name = CopyFileAllowDecryptedRemoteDestination
- Value = 1

레지스트리 키를 설정하면 네트워크 공유에 만들어진 모든 복사 작업에 적용됩니다.

브라우저에서 Azure Files를 사용할 때 웹앱에서 ConditionHeadersNotSupported 오류 발생

ConditionHeadersNotSupported 오류는 웹 브라우저와 같은 조건부 헤더를 사용하는 애플리케이션를 통해 Azure Files에 호스팅된 콘텐츠에 액세스할 때 액세스에 실패하는 경우 발생합니다. 이 오류는 조건 헤더가 지원되지 않는다는 것을 표시합니다.

ConditionHeadersNotSupported 오류 메시지를 보여 주는 스크린샷

원인

조건부 헤더는 아직 지원되지 않습니다. 이를 구현하는 애플리케이션은 파일이 액세스될 때마다 전체 파일을 요청해야 합니다.

해결 방법

새 파일이 업로드되면 기본적으로 CacheControl 속성은 no-cache입니다. 애플리케이션이 매번 파일을 요청하도록 하려면 파일의 CacheControl 속성을 no-cache에서 no-cache, no-store, must-revalidate로 업데이트해야 합니다. Azure Storage Explorer를 사용하여 업데이트할 수도 있습니다.

참고 항목

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유

Azure Files 연결 및 액세스 문제 해결(SMB)

적용 대상

Azure 파일 공유에 연결하거나 탑재할 수 없음

Azure 파일 공유를 탑재할 때 오류 5 발생

원인 1: 암호화되지 않은 통신 채널

원인 1의 해결 방법

원인 2: 가상 네트워크 또는 방화벽 규칙이 스토리지 계정에서 사용하도록 설정됨

원인 2의 해결 방법

원인 3: ID 기반 인증을 사용할 경우 공유 수준 권한이 올바르지 않음

원인 3의 해결 방법

Azure 파일 공유를 탑재 또는 탑재 해제하는 경우 오류 53, 오류 67 또는 오류 87 발생

원인 1: 포트 445 차단

원인 1의 해결 방법

원인 2: NTLMv1 사용

원인 2의 해결 방법

오류 코드 0x800704b3 실패

원인

솔루션

애플리케이션 또는 서비스가 탑재된 Azure Files 드라이브에 액세스할 수 없습니다.

원인

솔루션

"내 컴퓨터" 또는 "이 PC"에 드라이브 문자를 가진 폴더가 없습니다.

원인

솔루션

내 스토리지 계정에 슬래시(/)가 포함되는 경우 net use 명령이 실패합니다.

원인

솔루션

"네트워크 리소스 유형이 올바르지 않음" 오류로 New-PSDrive 명령 실패

원인

솔루션

Azure 파일 공유에 액세스, 수정 또는 삭제할 수 없음(또는 스냅샷 공유)

고객이 시작한 장애 조치(failover) 후 "사용자 이름 또는 암호가 잘못되었습니다." 오류

Azure 파일 공유에 액세스하거나 삭제하려고 할 때 "액세스 권한 없음" 오류 발생

원인 1: 가상 네트워크 또는 방화벽 규칙이 스토리지 계정에서 사용하도록 설정됨

원인 1의 해결 방법

원인 2: 사용자 계정에 스토리지 계정에 대한 액세스 권한이 없음

원인 2의 해결 방법

파일 잠금 및 임대

파일 또는 디렉터리를 수정, 이동/이름 바꾸기 또는 삭제할 수 없음

연결 없는 파일 핸들 또는 임대

원인 1

솔루션 1

원인 2

해결 방법 2

Linux에서 Azure 파일 공유 스냅샷을 탑재할 수 없음

Linux에서 Azure 파일 공유 스냅샷을 탑재하려고 할 때 "탑재 오류(22): 잘못된 인수"

원인

솔루션

Linux에서 Azure 파일 공유 스냅샷을 탑재하려고 할 때 "잘못된 스냅샷 토큰"

원인

솔루션

Azure 파일 공유 스냅샷을 탑재하려고 할 때 "탑재 오류(2): 그러한 파일 또는 디렉터리가 없습니다."

원인

솔루션

너무 많은 열린 핸들로 인한 디스크 할당량 또는 네트워크 오류

오류 1816 - 할당량이 부족하여 이 명령을 처리할 수 없습니다.

원인

솔루션

핸들에서 작업을 수행할 때 ERROR_UNEXP_NET_ERR(59)

원인

솔루션

“암호화를 지원하지 않는 대상에 파일을 복사하는 중임” 오류 발생

원인

해결 방법

브라우저에서 Azure Files를 사용할 때 웹앱에서 ConditionHeadersNotSupported 오류 발생

원인

해결 방법

참고 항목

도움을 요청하십시오.

피드백

추가 리소스