다음을 통해 공유

NFS Azure 파일 공유 문제 해결

  • 아티클

참고 항목

이 문서에서 참조하는 CentOS는 Linux 배포이며 EOL(수명 종료)에 도달합니다. 사용 및 계획을 적절하게 고려하세요. 자세한 내용은 CentOS 수명 종료 지침을 참조 하세요.

이 문서에서는 NFS Azure 파일 공유와 관련된 일반적인 문제를 나열하고 잠재적인 원인과 해결 방법을 제공합니다.

Important

이 문서의 내용은 NFS 공유에만 적용됩니다. Linux에서 SMB 문제를 해결하려면 Linux에서 Azure Files 문제 해결(SMB)을 참조하세요. NFS Azure 파일 공유는 Windows에서 지원되지 않습니다.

적용 대상

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

chgrp "filename" 실패: 잘못된 인수(22)

원인 1: idmapping이 사용하지 않도록 설정되어 있지 않습니다.

Azure Files는 영숫자 UID/GID를 허용하지 않으므로 idmapping을 사용하지 않도록 설정해야 합니다.

원인 2: idmapping이 사용하지 않도록 설정되었지만 잘못된 파일/디렉터리 이름을 발견한 후 다시 사용하도록 설정되었습니다.

idmapping을 올바르게 사용하지 않도록 설정했더라도 경우에 따라 자동으로 다시 사용하도록 설정될 수 있습니다. 예를 들어 Azure Files가 잘못된 파일 이름을 발견하면 오류를 보냅니다. 이 오류 코드가 표시되면 NFS 4.1 Linux 클라이언트는 idmapping을 다시 사용하도록 설정하고 이후 요청은 영숫자 UID/GID를 사용하여 보냅니다. Azure Files에서 지원되지 않는 문자 목록은 이 문서를 참조하세요. 콜론은 지원되지 않는 문자 중 하나입니다.

해결 방법

idmapping을 사용하지 않도록 설정했고 다시 사용하도록 설정하는 항목이 없는지 확인합니다. 그런 후 다음 단계를 수행합니다.

  1. 공유를 분리합니다.

  2. 다음을 사용하여 idmapping을 사용하지 않도록 설정합니다.

    sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping

  3. 공유를 다시 탑재합니다.

  4. rsync를 실행하는 경우 잘못된 디렉터리 또는 파일 이름이 없는 디렉터리의 인수를 사용하여 rsync —numeric-ids 를 실행합니다.

NFS 공유를 만들 수 없음

원인: 지원되지 않는 스토리지 계정 설정

NFS는 다음 구성을 사용하는 스토리지 계정에서만 사용할 수 있습니다.

솔루션

NFS 공유를 만드는 방법의 지침을 따르세요.

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

원인 1: 신뢰할 수 없는 네트워크/신뢰할 수 없는 IP의 클라이언트에서 요청이 시작되었습니다.

SMB와 달리 NFS는 사용자 기반 인증을 사용하지 않습니다. 공유에 대한 인증은 네트워크 보안 규칙 구성을 기반으로 합니다. 클라이언트가 NFS 공유에 대한 보안 연결만 설정하도록 하려면 서비스 엔드포인트나 프라이빗 엔드포인트를 사용해야 합니다. 프라이빗 엔드포인트 외에도 온-프레미스에서 공유에 액세스하려면 VPN 또는 ExpressRoute 연결을 설정해야 합니다. 방화벽에 대한 스토리지 계정의 허용 목록에 추가된 IP는 무시됩니다. NFS 공유에 대한 액세스를 설정하려면 다음 방법 중 하나를 사용해야 합니다.

  • 서비스 엔드포인트

    • 공용 엔드포인트에서 액세스합니다.

    • 같은 지역에서만 사용할 수 있습니다.

    • 공유 액세스에 VNet 피어링을 사용할 수 없습니다.

    • 각 가상 네트워크 또는 서브넷은 허용 목록에 개별적으로 반드시 추가해야 합니다.

    • 온-프레미스 액세스의 경우, ExpressRoute, 지점 및 사이트 간 VPN, 사이트 간 VPN에서 서비스 엔드포인트를 사용할 수 있습니다. 프라이빗 엔드포인트가 더 안전하기 때문에 사용하는 것을 권장합니다.

      다음 다이어그램에서는 퍼블릭 엔드포인트를 사용한 연결을 보여 줍니다.

      공용 엔드포인트 연결 다이어그램.

  • 프라이빗 엔드포인트

    • 액세스는 서비스 엔드포인트보다 더 안전합니다.

    • 프라이빗 링크를 통한 NFS 공유에 대한 액세스는 스토리지 계정의 Azure 지역 내부 및 외부(지역 간, 온-프레미스)에서 사용할 수 있습니다.

    • 프라이빗 엔드포인트에서 호스팅되는 Virtual Network와 가상 네트워크 피어링을 통해 피어링된 Virtual Network의 클라이언트에 대한 NFS 공유 액세스 권한을 부여합니다.

    • ExpressRoute, point-to-site VPNs, 지점 및 사이트 간 VPN, 사이트 간 VPN에서 프라이빗 엔드포인트를 사용할 수 있습니다.

      프라이빗 엔드포인트 연결 다이어그램.

원인 2: 보안 전송 필요가 사용하도록 설정되어 있습니다.

NFS Azure 파일 공유는 현재 이중 암호화를 지원하지 않습니다. Azure는 MACSec를 사용하여 Azure 데이터 센터 간에 전송 중인 모든 데이터에 대한 암호화를 제공합니다. NFS 공유는 신뢰할 수 있는 가상 네트워크와 VPN 터널을 통해서만 액세스할 수 있습니다. NFS 공유에서 추가 전송 계층 암호화를 사용할 수 없습니다.

솔루션

스토리지 계정의 구성 블레이드에서 필요한 보안 전송을 사용하지 않도록 설정합니다.

필요한 보안 전송을 사용하지 않도록 설정하는 스토리지 계정 구성 블레이드를 보여 주는 스크린샷.

원인 3: nfs-utils, nfs-client 또는 nfs-common 패키지가 설치되지 않음

명령을 실행 mount 하기 전에 nfs-utils, nfs-client 또는 nfs-common 패키지를 설치합니다.

NFS 패키지가 설치되어 있는지 확인하려면 다음을 실행합니다.

이 섹션의 동일한 명령은 CentOS 및 Oracle Linux에 적용됩니다.

sudo rpm -qa | grep nfs-utils

솔루션

패키지가 설치되어 있지 않으면 distro-specific 명령을 사용하여 패키지를 설치합니다.

이 섹션의 동일한 명령은 CentOS 및 Oracle Linux에 적용됩니다.

OS 버전 7.X

sudo yum install nfs-utils

OS 버전 8.X 또는 9.X

sudo dnf install nfs-utils

원인 4: 방화벽 차단 포트 2049

NFS 프로토콜은 포트 2049를 통해 서버와 통신합니다. 이 포트가 스토리지 계정(NFS 서버)에 열려 있는지 확인합니다.

솔루션

다음 명령을 실행하여 클라이언트에서 포트 2049가 열려 있는지 확인합니다. 포트가 열려 있지 않은 경우 엽니다.

sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049

원인 5: 스토리지 계정이 삭제됨

오류로 인해 파일 공유를 탑재할 수 없는 경우: 연결 시간이 초과되면 파일 공유가 포함된 스토리지 계정이 실수로 삭제될 수 있습니다.

솔루션

스토리지 계정을 복구합니다. 그런 다음 새 스토리지 계정 리소스 ID와 연결되도록 프라이빗 엔드포인트를 삭제하고 다시 만듭니다.

일부 커널에서 큰 디렉터리 열거형에 대해 ls 중단

원인: Linux 커널 v5.11에서 버그가 도입되었으며 v5.12.5에서 수정되었습니다.

일부 커널 버전에는 디렉터리 목록이 무한 READDIR 시퀀스를 발생시키는 버그가 있습니다. 한 번의 호출로 모든 항목을 배송할 수 있는 작은 디렉터리는 문제가 되지 않습니다. 버그가 Linux 커널 v5.11에서 도입되었으며 v5.12.5에서 수정되었습니다. 따라서 두 버전 사이의 모든 버전에는 버그가 있습니다. RHEL 8.4 에 이 커널 버전이 있습니다.

해결 방법: 커널 다운그레이드 또는 업그레이드

영향을 받는 커널 외부로 커널을 다운그레이드하거나 업그레이드하면 문제가 해결됩니다.

"파일을 찾을 수 없음" 오류로 시스템 명령이 실패합니다.

원인

NFS 서비스에서 생성된 64비트 inode 숫자의 서식으로 인해 Inode 번호를 사용하는 Linux 32비트 애플리케이션이 Azure Files에서 예상대로 작동하지 않을 수 있습니다.

솔루션

이 문제를 해결하려면 다음 방법 중 하나를 사용합니다.

  • 커널 부팅 옵션을 사용하여 nfs.enable_ino64=0 64비트 inode 숫자를 32비트로 압축합니다.

  • /etc/modprobe.d/nfs.conf 파일에 추가하고 options nfs enable_ino64=0 VM을 다시 부팅하여 모듈 매개 변수를 설정합니다.

grub.conf 파일에서 이 커널 부팅 옵션을 유지할 수도 있습니다. 자세한 내용은 Linux 배포에 대한 설명서를 참조하세요.

파일 및 디렉터리 소유권을 변경할 수 없음

원인

NFS 파일 공유에 대한 권한은 Azure Files 서비스가 아닌 클라이언트 OS에 의해 적용됩니다. NFS 파일 공유에서 루트 Squash 설정을 사용하는 경우 클라이언트 시스템의 루트 사용자는 액세스 제어를 위해 익명(권한이 없는) 사용자로 처리됩니다. 즉, 클라이언트 시스템에 루트로 로그인한 경우에도 이 명령을 사용하여 chown 소유하지 않은 파일 및 디렉터리의 소유권을 변경할 수 없습니다.

솔루션

Azure Portal에서 파일 공유로 이동하고 속성을 선택합니다. 루트 스쿼시 설정을 루트 스쿼시 없음으로 변경합니다. 자세한 내용은 Azure Files에 대한 루트 스쿼시 구성을 참조 하세요.

루트 스쿼시를 사용할 수 없으므로 클라이언트 시스템의 루트 사용자는 서버 시스템의 루트 사용자와 동일한 권한을 갖습니다. 이제 현재 소유자에 관계없이 공유에 있는 파일 또는 디렉터리의 소유권을 변경하는 데 사용할 chown 수 있습니다. 변경한 후 필요한 경우 루트 스쿼시를 다시 사용하도록 설정할 수 있습니다.

도움이 필요하신가요?

도움이 필요한 경우 지원에 문의하여 문제를 신속하게 해결하세요.

참고 항목

도움을 요청하십시오.

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