☰

NFS 마운트: 소유자는 none:nogroup입니다.

tag-icon • tag-icon nfs
NFS 마운트: 소유자는 none:nogroup입니다.

다음 코드를 사용하여 셸에서 NFS 파일 시스템을 마운트했습니다.

LINE='nfs.mit.edu:/export/evodesign/beatdb /beatdb nfs tcp,intr,rw 0 0'
grep "$LINE" /etc/fstab >/dev/null || echo $LINE >> /etc/fstab
mkdir /beatdb
mount -a # Remount /etc/fstab Without Reboot in Linux

파일을 none:nogroup:으로 표시합니다.

여기에 이미지 설명을 입력하세요

이 문제를 해결하고 올바른 소유자를 표시할 아이디어가 있습니까?

우분투 12.04를 사용합니다.

편집하다:

클라이언트측(NFS 서버에 액세스할 수 없음):

rpcidmapd실행 중:

여기에 이미지 설명을 입력하세요

rpcinfo -p:

여기에 이미지 설명을 입력하세요

/etc/idmapd.conf:

여기에 이미지 설명을 입력하세요

답변1

현지 지원이나 문서를 요청하는 것은 매우 좋은 생각인 것 같습니다 :).

체크리스트 형식으로, 당신이 필요하다고 생각합니다

1) 클라이언트 시스템에 생성된 필수 사용자. 이 작업은 수동으로 수행할 수 있지만 구성할 수 있는 자동 "디렉토리 서비스"가 있을 것으로 예상해야 합니다. LDAP일 수도 있습니다.

2) 클라이언트와 서버 간의 사용자 매핑. NFS4에서(tcp 옵션에 의해 암시됨)이것은 gareth가 언급한 것처럼 idmapd에 의해 처리됩니다. 서버가 생각하는 것과 일치하도록 도메인을 설정하기만 하면 됩니다. 크로스 도메인이 작동하지 않습니다. Linux의 한계인 것 같습니다.

3) 서버에 자신을 인증하기 위한 kerberos(NFS4에서 사용 가능) "아무도"가 아닌 다른 사람으로 파일에 액세스하려면 이것이 반드시 필요합니다. 먼저 Kerberos를 구성하고 테스트하는 것이 좋습니다. 구성에는 도메인 설정이 포함됩니다. idmapd.conf에서 동일한 도메인을 설정하게 됩니다.

또는 NFS3 스타일 인증을 사용하면 3)을 건너뛰고 2) 대신 사용자의 숫자 UID가 서버의 숫자 UID와 일치하는지 확인하면 됩니다. 이는 서버가 클라이언트를 신뢰하는 경우에만 사용됩니다 :).

답변2

비슷한 문제를 추적했습니다. /etc/idmapd.conf Verbosity=3을 설정하면 Ubuntu의 일부 문제를 확인하는 데 도움이 되었지만 전부는 아닙니다. 내 연구 결과를 요약하면 다음과 같습니다.

/etc/passwd 및 그룹 파일이 공유를 제공하는 시스템과 동일한 사용자/그룹을 공유하지 않을 가능성이 여전히 있습니다. 다음은 로컬 컴퓨터에 유사한 사용자/그룹 이름 매핑이 있어야 한다는 힌트입니다. /etc/nsswitch.conf를 사용하지 않으면 idmapd의 매핑 작업이 실패합니다. Verbosity=3을 실행하면 /var/log/syslog에 다음과 같은 항목이 표시됩니다.

idmapd[25193]: 클라이언트 64: (그룹) 이름 "TheGroupNameYouExpected" -> id "65534

파일이 아닌 다른 항목(예: ldap 또는 nis)에 매핑하도록 /etc/nsswitch.conf를 수정하는 경우 ldap 또는 nis에 ID 변환을 원하는 사용자 이름 또는 그룹 이름에 대한 일종의 항목이 실제로 있는지 확인해야 합니다. 을 위한. 항목이 존재하지 않으면 idmapd는 사용자/그룹을 성공적으로 매핑하지 못합니다.

관련 문제에서 RHEL v7에 대해 발견한 idmapd.conf 서비스는 더 이상 NFS 클라이언트에 대해 활성화할 필요가 없습니다.

https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c2

그러나 위 스레드에는 기본적으로 자동 ID-사용자 이름 매핑을 수행하는 서비스의 메모리에 매핑된 상태로 유지되는 ID 수가 매우 적다는 문제가 있습니다. 오류를 기록하는 대신 idmapd는 200명 이상의 사용자 번역을 거부합니다. 현재 커널 설정에서 이를 확인할 수 있습니다.

cat /proc/sys/kernel/keys/root_maxkeys

대부분 200이 기본 설정입니다. NFS 마운트 지점이 사용 가능한 모든 사용자를 적절하게 매핑하도록 하려면 이 파일을 변경해야 합니다.

/etc/sysctl.conf

다음과 같이 해당 줄을 추가하거나 수정합니다.

# To ensure we can map all the possible NFS users
kernel.keys.root_maxkeys=65000
kernel.keys.root_maxbytes=1300000
kernel.keys.maxkeys=65000
kernel.keys.maxbytes=1300000

시스템에 많은 사용자/ID 키 매핑이 필요하지 않을 수 있으므로 필요에 따라 조정하십시오. 이렇게 하면 NFS 마운트를 사용하는 동안 모든 ID-이름 키가 매핑된 상태로 유지됩니다. 다음은 현재 커널 설정을 보여주는 또 다른 관련 게시물입니다.

https://bugzilla.redhat.com/show_bug.cgi?id=876705#c20

다음 값에 대해:

cat /proc/sys/kernel/keys/root_maxkeys
cat /proc/sys/kernel/keys/root_maxbytes
cat /proc/sys/kernel/keys/maxkeys
cat /proc/sys/kernel/keys/maxbytes

대부분의 경우 maxbytes 및 root_maxbytes는 모든 키를 저장할 만큼 충분히 커야 합니다.

https://www.kernel.org/doc/Documentation/security/keys.txt

답변3

Kerberos를 사용하여 NFSv4를 수행한다고 가정하는 또 다른 체크리스트는 다음과 같습니다.

  • kinit, 다음을 보세요 klist. 티켓이 보일 것입니다. 그렇지 않은 경우 먼저 Kerberos 인증을 수정하는 방법에 대한 답변을 찾아보세요.
  • 달리고 있어 rpc.gssd? 서비스를 시작하고 싶을 수도 있습니다. 또한 일부 배포판에서는 /etc/fstab.
  • 달리고 있어 rpc.idmapd? (다시 말하지만 이는 일반적으로 클라이언트 측 nfs 서비스에 의해 시작되어야 하며 ls /etc/init.d/좋은 출발점이 됩니다.
  • 보다 /etc/idmapd.conf. "도메인" 부분이 NFS 서버의 실제 도메인과 일치합니까? (... 다른 것이 없다면 Kerberos 영역을 사용해 볼 수 있습니다.) 이것이 필요하지 않은 배포판과 필요했던 배포판을 본 적이 있습니다. 어쩌면 일부에서는 FQDN에 대해 더 합리적인 기본값이 있을 수도 있습니다.
  • GSS_principal_attr = GSSAuthName파일에도 추가하세요 . 도메인만으로 일부 소유권 문제를 해결할 수 있지만 디렉터리 등의 경우에도 이것이 필요한 것 같습니다.
  • rpc.idmapd구성을 조정한 후 한 번 이상 다시 시작하세요 . 구성을 조정한 후 다시 마운트할 필요는 없지만 문제가 되지는 않습니다.
  • 또한! nfsidmap -c. 분명히 다시 시작해도 지워지지 않는 캐시가 있습니다. 이렇게 하면 지워집니다. (그렇지 않으면 수정이 작동하더라도 작동하지 않는다고 계속 생각할 수 있습니다.)

관련 정보