Linux 시스템에서 내보내어 Solaris 시스템에 설치된 파일 시스템입니다. Solaris 시스템에서는 이 파일 시스템의 일부 작업이 실패합니다. 특히:
$ touch z1; install --mode 0444 z1 z2
install: setting permissions for `z2': Operation not supported on transport endpoint
여기의 "설치 프로그램" 프로그램은 GNU coreutils 버전 6.12에서 가져온 것입니다.
이는 서버 측이 Network Appliance였을 때 작동했습니다.
"chmod"는 권한을 설정할 수 있지만 "install"은 설정할 수 없습니다. 정확히 무엇이 실패했는지 확인하기 위해 "트러스"를 실행했는데 다음과 같은 내용이 표시되었습니다.
facl(4, SETACL, 4, 0x0004A938) Err#122 EOPNOTSUPP
chmod에서 truss를 실행하면 다른 시스템 호출을 사용하고 있음을 알 수 있습니다.
chmod("z2", 0444) = 0
서버가 x86_64에서 RHEL 6.4를 실행 중입니다. 다음 옵션을 사용하여 파일 시스템을 내보냅니다.
rw,async
클라이언트는 sparc(sun4u)에서 Solaris 10(SunOS 5.1)을 실행 중입니다. 다음 옵션을 사용하여 파일 시스템을 마운트합니다.
remote/read/write/setuid/devices/rstchown/vers=3/xattr/dev=5d414f4
이 문제를 해결하기 위해 "vers=3"을 추가했지만 그렇지 않습니다.
Network Appliance가 파일 시스템을 제공할 때 이것이 잘 작동했다는 점을 고려하면 서버측 구성 방식과 관련이 있는 것으로 추측됩니다.
하지만 내 추측은 근거가 없을 수도 있다. 동일한 서버에서 동일한 클라이언트로 마운트된 두 개의 다른 ext4 파일 시스템에서는 이러한 동작이 나타나지 않는 것으로 나타났습니다. 그러나 이러한 경우의 설치 옵션은 다음과 같습니다.
remote/read/write/nosetuid/nodevices/rstchown/intr/hard/noquota/xattr/dev=5d41520
그리고
remote/read/write/setuid/devices/rstchown/intr/hard/noquota/xattr/dev=5d41521
공통 항목은 "intr/hard/noquota"입니다. 이것이 왜 변화를 가져올지 아시나요?
답변: @roaima가 올바른 방향으로 가고 있는 것으로 나타났습니다. 나는 기본 파일 시스템이 모두 ext4라고 생각했지만 어떤 이유로 그 중 일부(작업 파일 시스템)는 xfs였습니다. 문제의 파일 시스템을 xfs로 옮긴 다음 NFS를 통해 Solaris 시스템에 공유했을 때 모든 것이 예상대로 작동했습니다.