내 수염은 이제 회색이 되었고, 지난 수십 년 동안 NFS를 사용했던 것을 오랫동안 기억합니다.여기에 원본 RFC를 인용합니다.이는 오늘날 우리가 보유하고 있는 NFS의 기반을 제공합니다.RFC1094. 물론,그로부터 30년이 지났고 그로부터 몇 년이 지났습니다.질문은 다음과 같습니다.
그 사이에이제 구성 옵션을 통해 서버 측에서 링크를 해석하는 것이 가능해졌습니까?이렇게 하면 클라이언트 측 링크 해석과 관련된 여러 가지 문제가 확실히 해결될 것입니다!
아니면 내가 젖어 있고 내가 인용하는 내용은 더 이상 사용되지 않으며 기본적으로 서버 측에서 해결되고 문제 해결에서 토끼 구멍을 따라 토끼를 쫓고 있습니까?
아직 구식이고 해석된 클라이언트 측인 경우서버측 해석을 가능하게 하는 옵션이 없다면 절대 링크 대신 상대 링크를 사용하는 것이 도움이 될까요?
감사해요.
답변1
심볼릭 링크는 항상 클라이언트에 의해 해결됩니다. 거기에는 몇 가지 이유가 있습니다. 먼저 NFS 프로토콜에는 파일 핸들이라는 개념이 있습니다. 각 핸들은 디렉터리, 파일 또는 심볼릭 링크(및 기타)일 수 있는 파일 시스템 개체를 가리킵니다. 게다가,NFSv4.1사양은 분명히 다음과 같이 말합니다.
NFS 클라이언트에 의해 생성되거나 서버에서 로컬로 생성되는 경우 기호 링크의 데이터는 생성 시 해석되지 않고 단순히 저장됩니다.
둘째, 서버 측에서 심볼릭 링크를 처리하면 심볼릭 링크가 내보낸 파일 시스템의 외부를 가리킬 수 있으므로 추가 권한 규칙을 고려해야 합니다.
실제로 SAMBA 서버에는 심볼릭 링크를 따라갈 수 있는 옵션이 없습니다. 이는 (a) 원래 MS 파일 시스템에는 심볼릭 링크 개념이 없었고 (b) 파일 시스템 객체 유형인 심볼릭 링크가 추가되었기 때문입니다.SMB2. BTW 동작은 NFS 해석과 일치합니다.
서버는 심볼릭 링크를 평가해서는 안 됩니다.
필요한 경우 사용자 정의 파일 시스템 구현을 허용하는 몇 가지 사용자 공간 NFS 서버가 있습니다.
있는 경우좋은서버 측에서 심볼릭 링크를 해결하는 이유가 추가될 수 있습니다.
답변2
서버를 가리키는 동일한 NFS 마운트 설정을 사용하여 네트워크에 두 대의 컴퓨터가 있습니다. 서버에는 내보낸 디렉터리에서 다른 디렉터리로의 심볼릭 링크가 있습니다. 한 클라이언트에서는 링크가 제대로 작동하지만 다른 클라이언트에서는 신뢰할 수 없습니다. 작업 중인 클라이언트에 새 버전의 NFS(동일 프로토콜 사용)가 있으므로 버그가 수정된 것 같습니다. 이론적으로 요청은 서버로 이동하여 서버에서 내보내기를 수행하므로 서버에서 해석되어야 합니다. 클라이언트가 폴더에 심볼릭 링크를 넣으면 다른 클라이언트에서는 심볼릭 링크가 깨질 수 있습니다. 그러나 서버 심볼릭 링크는 작동해야 합니다. 이 일반 내용은 네트워크 공유를 위한 특별한 유형의 심볼릭 링크가 필요함을 시사합니다. 서버 심볼릭 링크와 같은 것입니다.