아래 시나리오에서 Windows의 애플리케이션은 업데이트된 버전의 파일을 가져오지 않고 이전 버전의 파일을 가져옵니다. 이 경우 새 버전을 얻는 방법에는 (1) Linux에서 Samba 서비스를 다시 시작하거나 (2) Remove-SmbMappingWindows에서 PowerShell 명령을 호출하는 두 가지 방법이 있습니다.
SMB 서버가 Windows일 때 이런 경험을 했는지는 잘 모르겠지만 아마도 기억이 나지 않아서 그런 것 같습니다. Linux의 파일 서버가 Samba인 경우에만 이 문제가 발생한다면 문제의 원인은 무엇입니까? 삼바 서버 오류? 윈도우 버그? 아니면 SMB 프로토콜 자체에 문제가 있는 걸까요?
- Samba(4.16.2)를 사용하여 Linux PC에서 디렉터리를 공유합니다.
- Windows PC에서는 이 디렉터리의 파일을 열고 파일을 닫습니다.
- Linux PC에서는 파일을 수정합니다.
- Windows PC에서는 파일을 다시 엽니다.
답변1
이것은 실수가 아닙니다. 이것은 "디자인의 결과"입니다.
간단히 말해서, Samba 서버는 전용 파일 서버로 작동할지 여부의 두 가지 모드로 작동할 수 있습니다.
전용 파일 서버의 기본 아이디어는 실제 저장 속도가 느리고 대부분의 사용자가 어쨌든 smb를 통해 파일에 액세스하므로 서버 메모리에 파일을 캐싱하는 것이 효율적이라는 것입니다. 파일 수정은 SMB를 우회할 것으로 예상되지 않습니다. 물론 캐시는 일정 기간이 지나면 만료되지만 사용자가 제어할 수 없습니다(언제 어디서 구성되었는지 확실하지 않거나 구성 가능한지 여부도 알 수 없음).
이에 대한 핵심은 "기회 잠금"입니다. oplockssmb.conf를 입력합니다.
공식 문서(https://www.oreilly.com/openbook/samba/book/ch05_05.html) 구체적으로 정의됨:
Unix 응용 프로그램(예: vi)과 SMB 클라이언트에서 동일한 파일에 액세스하는 경우 oplock을 비활성화해야 합니다...