Azure Files 연결 및 액세스 문제 해결(SMB)
이 문서에서는 Windows 또는 Linux 클라이언트에서 SMB(서버 메시지 블록) Azure 파일 공유에 연결하고 액세스하려고 할 때 발생할 수 있는 일반적인 문제를 나열합니다. 또한 이러한 문제에 대한 가능한 원인과 해결 방법도 제공합니다.
참고
이 문서가 도움이 되었나요? 귀하의 입력은 우리에게 중요합니다. 이 페이지의 피드백 단추를 사용하여 이 문서가 얼마나 잘 작동했는지 또는 어떻게 개선할 수 있는지 알려주세요.
중요
이 문서는 SMB 공유에만 적용됩니다. NFS(네트워크 파일 시스템) 공유에 대한 자세한 내용은 Azure NFS 파일 공유 문제 해결을 참조하세요.
적용 대상
| 파일 공유 형식 | SMB | Nfs |
|---|---|---|
| 표준 파일 공유(GPv2), LRS/ZRS | 
|
|
| 표준 파일 공유(GPv2), GRS/GZRS |
|
|
| 프리미엄 파일 공유(FileStorage), LRS/ZRS |
|
|
Azure 파일 공유에 연결하거나 탑재할 수 없음
Azure 파일 공유에 액세스하는 데 사용하는 클라이언트 운영 체제에 따라 Windows 또는 Linux 탭을 선택합니다.
Windows에서 Azure 파일 공유에 연결하려고 하면 다음과 같은 오류 메시지가 표시될 수 있습니다.
Azure 파일 공유를 탑재할 때 오류 5
- 시스템 오류 5가 발생했습니다. 액세스가 거부되었습니다.
원인 1: 암호화되지 않은 통신 채널
보안을 위해 통신 채널이 암호화되지 않고 Azure 파일 공유가 있는 동일한 데이터 센터에서 연결 시도가 이루어지지 않으면 Azure 파일 공유에 대한 연결이 차단됩니다. 스토리지 계정에서 보안 전송 필요 설정을 사용하도록 설정하면 동일한 데이터 센터 내의 암호화되지 않은 연결도 차단됩니다. 암호화된 통신 채널은 최종 사용자의 클라이언트 OS가 SMB 암호화를 지원하는 경우에만 제공됩니다.
각 시스템의 Windows 8, Windows Server 2012 이상 버전은 SMB 3을 포함하는 요청을 협상합니다.x- 암호화를 지원합니다.
원인 1에 대한 해결 방법
- SMB 암호화(Windows 8/Windows Server 2012 이상을 지원하는 클라이언트에서 연결합니다.
- Azure 파일 공유에 사용되는 Azure Storage 계정과 동일한 데이터 센터의 VM(가상 머신)에서 연결합니다.
- 클라이언트가 SMB 암호화를 지원하지 않는 경우 스토리지 계정에서 보안 전송 필요 설정을 사용하지 않도록 설정했는지 확인합니다.
원인 2: 스토리지 계정에서 가상 네트워크 또는 방화벽 규칙이 사용하도록 설정됨
클라이언트 IP 주소 또는 가상 네트워크가 허용 목록에 없는 한 VNET(가상 네트워크) 및 방화벽 규칙이 스토리지 계정에 구성된 경우 네트워크 트래픽이 거부됩니다.
원인 2에 대한 해결 방법
가상 네트워크 및 방화벽 규칙이 스토리지 계정에 올바르게 구성되었는지 확인합니다. 가상 네트워크 또는 방화벽 규칙이 문제를 일으키는지 테스트하려면 스토리지 계정의 설정을 일시적으로 모든 네트워크에서 액세스 허용으로 변경합니다. 자세한 내용은 Azure Storage 방화벽 및 가상 네트워크 구성을 참조하세요.
원인 3: ID 기반 인증을 사용할 때 공유 수준 권한이 잘못되었습니다.
사용자가 AD(Active Directory) 또는 Microsoft Entra Domain Services 인증을 사용하여 Azure 파일 공유에 액세스하는 경우 공유 수준 권한이 올바르지 않으면 "액세스 거부됨" 오류와 함께 파일 공유에 대한 액세스가 실패합니다.
원인에 대한 해결 방법 3
권한이 올바르게 구성되었는지 확인합니다.
Active Directory Domain Services(AD DS)는 공유 수준 권한 할당을 참조하세요.
공유 수준 권한 할당은 Microsoft Entra Connect Sync 또는 Microsoft Entra Connect 클라우드 동기화를 사용하여 AD DS에서 Microsoft Entra ID 동기화된 그룹 및 사용자에 대해 지원됩니다. 공유 수준 권한이 할당된 그룹 및 사용자가 지원되지 않는 "클라우드 전용" 그룹이 아닌지 확인합니다.
Microsoft Entra Domain Services공유 수준 권한 할당을 참조하세요.
Azure 파일 공유를 탑재하거나 탑재 해제할 때 오류 53, 오류 67 또는 오류 87
온-프레미스 또는 다른 데이터 센터에서 파일 공유를 탑재하려고 하면 다음과 같은 오류가 발생할 수 있습니다.
- 시스템 오류 53이 발생했습니다. 네트워크 경로를 찾지 못했습니다.
- 시스템 오류 67이 발생했습니다. 네트워크 이름을 찾을 수 없습니다.
- 시스템 오류 87이 발생했습니다. 매개 변수가 틀립니다.
원인 1: 포트 445가 차단됨
Azure Files 데이터 센터에 대한 포트 445 아웃바운드 통신이 차단된 경우 시스템 오류 53 또는 시스템 오류 67이 발생할 수 있습니다. 포트 445에서 액세스를 허용하거나 허용하지 않는 ISP의 요약을 보려면 TechNet으로 이동합니다.
방화벽 또는 ISP가 포트 445를 차단하는 경우 검사 AzFileDiagnostics 도구 또는 cmdlet을 Test-NetConnection 사용합니다.
cmdlet을 Test-NetConnection 사용하려면 Azure PowerShell 모듈을 설치해야 합니다. 자세한 내용은 Azure PowerShell 모듈 설치를 참조하세요. 및 <your-resource-group-name> 를 스토리지 계정의 관련 이름으로 바꿔 <your-storage-account-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 Files 사용하여 온-프레미스에서 Azure Storage 계정으로 VPN(가상 사설망) 또는 ExpressRoute를 설정하면 트래픽은 인터넷을 통한 것이 아니라 보안 터널을 통과합니다. 지침에 따라 Windows에서 Azure Files 액세스하도록 VPN을 설치합니다.
해결 방법 3 - ISP/IT 관리자의 도움을 받아 포트 445 차단 해제 IT 부서 또는 ISP와 협력하여 Azure IP 범위에 대한 포트 445 아웃바운드를 엽니다.
해결 방법 4 - Storage Explorer 또는 PowerShell과 같은 REST API 기반 도구 Azure Files 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 파일 탐색기 관리자 권한으로 실행되지 않습니다. 관리 명령 프롬프트에서 실행하는 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 확인 및 파일 공유에 대한 연결을 검사 있는지 확인합니다.
Azure 파일 공유에 액세스, 수정 또는 삭제할 수 없음(또는 스냅샷 공유)
고객이 시작한 장애 조치(failover) 후 "사용자 이름 또는 암호가 잘못되었습니다." 오류
지역 중복 스토리지 계정이 있는 고객이 시작한 장애 조치(failover) 시나리오에서는 파일 핸들 및 임대가 장애 조치(failover)에 유지되지 않습니다. 클라이언트는 파일 공유를 분리하고 다시 탑재해야 합니다.
Azure 파일 공유에 액세스하거나 삭제하려고 할 때 "액세스 권한 없음" 오류
Azure Portal 사용하여 Azure 파일 공유에 액세스하거나 삭제하려고 하면 다음 오류가 발생할 수 있습니다.
액세스 권한 없음 오류 코드: 403
원인 1: 스토리지 계정에서 가상 네트워크 또는 방화벽 규칙이 사용하도록 설정됨
원인 1에 대한 해결 방법
가상 네트워크 및 방화벽 규칙이 스토리지 계정에 올바르게 구성되었는지 확인합니다. 가상 네트워크 또는 방화벽 규칙이 문제를 일으키는지 테스트하려면 스토리지 계정의 설정을 일시적으로 모든 네트워크에서 액세스 허용으로 변경합니다. 자세한 내용은 Azure Storage 방화벽 및 가상 네트워크 구성을 참조하세요.
원인 2: 사용자 계정에 스토리지 계정에 대한 액세스 권한이 없습니다.
원인 2에 대한 해결 방법
Azure 파일 공유가 있는 스토리지 계정으로 이동하여 액세스 제어(IAM)를 선택하고 사용자 계정에 스토리지 계정에 대한 액세스 권한이 있는지 확인합니다. 자세한 내용은 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 스토리지 계정을 보호하는 방법을 참조하세요.
파일 잠금 및 임대
Azure 파일 공유 또는 스냅샷 수정하거나 삭제할 수 없는 경우 파일 잠금 또는 임대 때문일 수 있습니다. Azure Files Azure 파일 공유의 실수로 수정 또는 삭제를 방지하고 스냅샷을 공유하는 두 가지 방법을 제공합니다.
스토리지 계정 리소스 잠금: 스토리지 계정을 포함한 모든 Azure 리소스는 리소스 잠금을 지원합니다. 관리자 또는 Azure Backup 같은 서비스에서 스토리지 계정에 잠금을 배치할 수 있습니다. 리소스 잠금의 두 가지 변형이 있습니다. 즉, 스토리지 계정 및 해당 리소스에 대한 모든 수정을 방지하는 수정 및 삭제는 스토리지 계정 및 해당 리소스의 삭제만 방지합니다. 리소스 공급자를 통해
Microsoft.Storage공유를 수정하거나 삭제할 때 리소스 잠금은 Azure 파일 공유 및 공유 스냅샷에 적용됩니다. 이름(예Get-AzRmStorageShare: )이 인 Azure Files 대한 cmdlet을 Azure PowerShellRm대부분의 포털 작업과 명령 그룹의 Azure CLI 명령share-rm(예:az storage share-rm list)은 리소스 공급자를Microsoft.Storage사용합니다. 이름(예Get-AzStorageShare: )이 없는RmStorage Explorer, 레거시 Azure Files PowerShell 관리 cmdlet, 명령 그룹 아래의 레거시 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 같은 부가 가치 서비스에 의해 리소스 잠금/임대를 제거할 수 있습니다. 다음 스크립트는 모든 리소스 잠금 및 임대를 제거합니다. 및 <storage-account> 을 사용자 환경에 적합한 값으로 바꿔 <resource-group> 야 합니다.
다음 스크립트를 실행하기 전에 최신 버전의 Azure Storage PowerShell 모듈을 설치해야 합니다.
중요
리소스 잠금을 수행하고 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에서 다음과 같은 오류가 표시될 수 있습니다.
분리된 파일 핸들 또는 임대
파일 공유의 주요 목적 중 하나는 여러 사용자와 애플리케이션이 동시에 공유의 파일 및 디렉터리와 상호 작용할 수 있다는 것입니다. 이러한 상호 작용을 지원하기 위해 파일 공유는 파일 및 디렉터리에 대한 액세스를 중재하는 여러 가지 방법을 제공합니다.
SMB를 통해 탑재된 Azure 파일 공유에서 파일을 열면 애플리케이션/운영 체제에서 파일에 대한 참조인 파일 핸들을 요청합니다. 무엇보다도 애플리케이션은 파일 핸들을 요청할 때 파일 공유 모드를 지정합니다. 이 모드는 Azure Files 적용된 파일에 대한 액세스의 독점 수준을 지정합니다.
None: 단독 액세스 권한이 있습니다.Read: 파일을 여는 동안 다른 사용자가 파일을 읽을 수 있습니다.Write: 열려 있는 동안 다른 사용자가 파일에 쓸 수 있습니다.ReadWrite: 및Write공유 모드의Read조합입니다.Delete: 열려 있는 동안 다른 사용자가 파일을 삭제할 수 있습니다.
상태 비저장 프로토콜인 FileREST 프로토콜에는 파일 핸들의 개념이 없지만 스크립트, 애플리케이션 또는 서비스에서 사용할 수 있는 파일 및 폴더에 대한 액세스를 중재하는 유사한 메커니즘인 파일 임대를 제공합니다. 파일이 임대되면 파일 공유 모드 None가 인 파일 핸들과 동일한 것으로 처리됩니다.
파일 핸들 및 임대는 중요한 용도로 사용되지만 파일 핸들과 임대가 분리될 수 있는 경우도 있습니다. 이 경우 파일 수정 또는 삭제에 문제가 발생할 수 있습니다. 다음과 같은 오류 메시지가 표시될 수 있습니다.
- 파일이 다른 프로세스에서 사용 중이므로 프로세스에서 파일에 액세스할 수 없습니다.
- 파일이 다른 프로그램에서 열려 있으므로 작업을 완료할 수 없습니다.
- 문서가 다른 사용자가 편집하기 위해 잠겨 있습니다.
- 지정된 리소스는 SMB 클라이언트에 의해 삭제될 것으로 표시됩니다.
이 문제에 대한 해결 방법은 분리된 파일 핸들 또는 임대로 인해 발생하는지에 따라 달라집니다.
참고
REST 임대는 파일이 삭제되거나 수정되지 않도록 애플리케이션에서 사용됩니다. 임대를 중단하기 전에 임대를 획득하는 애플리케이션을 식별해야 합니다. 그렇지 않으면 애플리케이션 동작이 중단될 수 있습니다.
원인 1
파일 핸들을 사용하면 파일/디렉터리가 수정되거나 삭제되지 않습니다. Get-AzStorageFileHandle PowerShell cmdlet을 사용하여 열린 핸들을 볼 수 있습니다.
모든 SMB 클라이언트가 파일/디렉터리에서 열린 핸들을 닫았고 문제가 계속 발생하는 경우 파일 핸들을 강제로 닫을 수 있습니다.
해결 방법 1
파일 핸들을 강제로 닫히려면 Close-AzStorageFileHandle PowerShell cmdlet을 사용합니다.
참고
및 Close-AzStorageFileHandle cmdlet은 Get-AzStorageFileHandle Az PowerShell 모듈 버전 2.4 이상에 포함되어 있습니다. 최신 Az PowerShell 모듈을 설치하려면 Azure PowerShell 모듈 설치를 참조하세요.
원인 2
파일 임대로 인해 파일이 수정되거나 삭제되지 않습니다. 파일에 다음 PowerShell 명령을 사용하여 파일 임대가 있는 경우 검사 수 있습니다. , <storage-account>, <file-share>및 <path-to-file> 를 사용자 환경에 적합한 값으로 바꿉<resource-group>니다.
# 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에서 Azure 파일 공유 스냅샷 탑재할 수 없음
Linux에서 Azure 파일 공유 스냅샷 탑재하려고 할 때 "탑재 오류(22): 잘못된 인수"입니다.
원인
snapshot 명령에 대한 mount 옵션이 인식된 형식으로 전달되지 않으면 이 오류로 명령이 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 탭을 선택합니다.
오류 1816 - 이 명령을 처리하는 데 할당량이 부족합니다.
원인
Azure 파일 공유의 파일 또는 디렉터리에 허용되는 동시 열린 핸들의 상한에 도달하면 오류 1816이 발생합니다. 자세한 내용은 Azure Files 확장 대상을 참조하세요.
해결 방법
일부 핸들을 닫아 동시 열린 핸들 수를 줄인 다음 다시 시도합니다. 자세한 내용은 Microsoft Azure Storage 성능 및 확장성 검사 목록을 참조하세요.
파일 공유, 디렉터리 또는 파일에 대한 열린 핸들을 보려면 Get-AzStorageFileHandle PowerShell cmdlet을 사용합니다.
파일 공유, 디렉터리 또는 파일에 대한 열린 핸들을 닫려면 Close-AzStorageFileHandle PowerShell cmdlet을 사용합니다.
참고
및 Close-AzStorageFileHandle cmdlet은 Get-AzStorageFileHandle Az PowerShell 모듈 버전 2.4 이상에 포함되어 있습니다. 최신 Az PowerShell 모듈을 설치하려면 Azure PowerShell 모듈 설치를 참조하세요.
핸들에서 작업을 수행할 때 ERROR_UNEXP_NET_ERR(59)
원인
오랫동안 많은 수의 열린 핸들을 캐시/보유하는 경우 제한 이유로 인해 이 서버 쪽 오류가 표시될 수 있습니다. 클라이언트에서 많은 수의 핸들을 캐시하는 경우 이러한 핸들의 대부분은 동시에 다시 연결 단계로 전환되어 제한해야 하는 서버에 큐를 작성할 수 있습니다. 다시 연결에 대한 다시 시도 논리 및 백 엔드의 제한은 클라이언트의 시간 제한보다 오래 걸립니다. 이 상황은 클라이언트가 ERROR_UNEXP_NET_ERR(59)로 인해 모든 작업이 실패하면서 모든 작업에 기존 핸들을 사용할 수 없음으로 나타납니다.
또한 클라이언트 핸들이 서버에서 연결이 끊어지는 경우(예: 몇 분 동안 지속되는 네트워크 중단) 이 오류가 발생할 수 있습니다.
해결 방법
많은 수의 핸들을 캐시된 상태로 유지하지 마세요. 핸들을 닫은 다음 다시 시도합니다. 및 Close-AzStorageFileHandle PowerShell cmdlet을 사용하여 Get-AzStorageFileHandle 열린 핸들을 보거나 닫습니다.
Azure 파일 공유를 사용하여 대규모 가상 데스크톱 배포 또는 파일, 디렉터리 및/또는 루트 디렉터리에 대한 핸들을 여는 다른 워크로드에 대한 프로필 컨테이너 또는 디스크 이미지를 저장하는 경우 동시 열린 핸들에 대한 상한 값 에 도달할 수 있습니다. 이 경우 추가 Azure 파일 공유를 사용하고 공유 간에 컨테이너 또는 이미지를 배포합니다.
오류 "암호화를 지원하지 않는 대상으로 파일을 복사하고 있습니다."
네트워크를 통해 파일을 복사하면 원본 컴퓨터에서 파일이 암호 해독되고, 일반 텍스트로 전송되고, 대상에서 다시 암호화됩니다. 그러나 암호화된 파일을 복사하려고 할 때 다음 오류가 표시될 수 있습니다. "암호화를 지원하지 않는 대상으로 파일을 복사하고 있습니다."
원인
이 문제는 EFS(파일 시스템 암호화)를 사용하는 경우에 발생할 수 있습니다. BitLocker로 암호화된 파일을 Azure Files 복사할 수 있습니다. 그러나 Azure Files NTFS EFS를 지원하지 않습니다.
해결 방법
네트워크를 통해 파일을 복사하려면 먼저 암호를 해독해야 합니다. 다음 방법 중 하나를 사용합니다.
- 복사 /d 명령을 사용합니다. 암호화된 파일을 대상에서 암호 해독된 파일로 저장할 수 있습니다.
- 다음 레지스트리 키를 설정합니다.
- 경로 = HKLM\Software\Policies\Microsoft\Windows\System
- 값 형식 = DWORD
- 이름 = CopyFileAllowDecryptedRemoteDestination
- 값 = 1
레지스트리 키를 설정하면 네트워크 공유에 수행되는 모든 복사 작업에 영향을 줍니다.
브라우저에서 Azure Files 사용하여 웹 애플리케이션에서 ConditionHeadersNotSupported 오류 발생
ConditionHeadersNotSupported 오류는 웹 브라우저와 같은 조건부 헤더를 사용하는 애플리케이션을 통해 Azure Files 호스트되는 콘텐츠에 액세스하는 데 실패할 때 발생합니다. 이 오류는 조건 헤더가 지원되지 않는다는 것을 표시합니다.
원인
조건부 헤더는 아직 지원되지 않습니다. 이를 구현하는 애플리케이션은 파일에 액세스할 때마다 전체 파일을 요청해야 합니다.
해결 방법
새 파일이 업로드되면 기본적으로 CacheControl 속성은 no-cache입니다. 애플리케이션이 매번 파일을 요청하도록 강제하려면 파일의 CacheControl 속성을 no-cache 에서 no-cache, no-store, must-revalidate로 업데이트해야 합니다. 이 작업은 Azure Storage Explorer 사용하여 수행할 수 있습니다.
참고 항목
- 문제 해결 Azure Files
- Azure Files 성능 문제 해결
- Azure Files 인증 및 권한 부여(SMB) 문제 해결
- Linux에서 Azure Files 일반적인 SMB 문제 해결
- Linux에서 Azure Files 일반적인 NFS 문제 해결
- Azure 파일 동기화 문제 해결
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기