☰

NFS 마운트: 소유자가 없음: nogroup

tag-icon • tag-icon nfs
NFS 마운트: 소유자가 없음: 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

파일을 아무도 없음: 그룹 없음으로 표시합니다.

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

이 문제를 해결하고 올바른 소유자를 표시할 수 있는 방법이 있나요?

우분투 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 스타일 인증을 사용하면 2) 대신 3)을 건너뛰게 되며 사용자의 숫자 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에서는 더 이상 NFS 클라이언트에 대해 idmapd.conf 서비스를 활성화할 필요가 없다는 사실을 발견했습니다.

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. 분명히 재부팅 후에도 지워지지 않는 캐시가 있습니다. (그렇지 않으면 수정이 작동하더라도 작동하지 않는다고 계속 생각할 수 있습니다.)

관련 정보