여기에는 Windows XP 프로필을 호스팅하도록 구성된 Samba 서버 (Debian 5.0)가 있습니다.
클라이언트는이 서버에 연결하여 삼바 공유에서 직접 프로파일 작업을 수행합니다 (프로파일은 로컬로 복사되지 않음).
때때로 클라이언트가 제대로 종료되지 않아 Windows가 파일 잠금을 해제하지 않습니다. Samba 잠금 테이블을 보면 클라이언트가 더 이상 연결되어 있지 않아도 많은 파일이 여전히 잠겨 있음을 알 수 있습니다. 우리의 경우, 이것은 Mozilla Thunderbird와 Firefox가 만든 잠금 파일에서 발생하는 것으로 보입니다. 삼바 잠금 테이블의 예는 다음과 같습니다.
# smbstatus -L | grep DENY_ALL | head -n5
Pid Uid DenyMode Access R/W Oplock SharePath Name Time
--------------------------------------------------------------------------------------------------
15494 10345 DENY_ALL 0x3019f RDWR EXCLUSIVE+BATCH /home/CORP/user1 app.profile/user1.thunderbird/parent.lock Mon Nov 22 07:12:45 2010
18040 10454 DENY_ALL 0x3019f RDWR EXCLUSIVE+BATCH /home/CORP/user2 app.profile/user2.thunderbird/parent.lock Mon Nov 22 11:20:45 2010
26466 10056 DENY_ALL 0x3019f RDWR EXCLUSIVE+BATCH /home/CORP/user3 app.profile/user3.firefox/parent.lock Mon Nov 22 08:48:23 2010
우리는 파일이 Windows에 의해 열리고 DENY_ALL 잠금을 부과 한 것을 볼 수 있습니다.
이제 클라이언트가이 공유에 다시 연결하여 해당 파일을 열려고하면 Samba는 파일이 잠겨 있고 액세스를 거부한다고 말합니다.
이 상황을 해결할 수있는 방법이 있습니까? 아니면 뭔가 빠졌습니까?
편집 : 우리는 Samba 서버에서 파일 잠금을 사용하지 않도록 설정 해야하는 이유 가 있기 때문에 파일 잠금을 사용하지 않도록 설정하고 싶습니다 .
답변
아래 단계를 통해 여러 가지 상황 에서이 정확한 문제를 해결하는 데 도움이되었습니다.
- samba 서버에 로그인하십시오.
- “smbstatus”를 실행하십시오.
- 출력의 세 번째 섹션에서 파일에 잠금이있는 프로세스의 pid를 찾으십시오.
- smbstatus 출력의 첫 번째 및 두 번째 섹션에서 예상되는 사용자 및 호스트 이름과 일치하는지 확인하십시오.
- “ps -ef”를 실행하고 해당 pid가있는 smbd가 얼마나 오래 실행되었는지 확인하십시오.
- 컴퓨터를 마지막으로 다시 부팅하기 전부터 실행 중이었다면 smbd가 남았습니다. 단지 하나의 smbd를 죽여라. (그리고 올바른 것을 얻으십시오-부모 pid가 1이 아닌 것이어야합니다.)
답변
살펴보십시오 :
reset on zero vc = yes / no
문제가 해결되는지 확인하십시오.
로부터 smb.conf매뉴얼 페이지
이 부울 옵션은 들어오는 세션 설정이 동일한 IP에서 오는 다른 연결을 종료해야하는지 여부를 제어합니다. 이것은 기본 Windows 2003 동작과 일치합니다. 비정상적인 네트워크가 있고 이전 연결에 여전히 공유 모드가있는 파일이있는 동안 Windows가 다시 연결하기로 결정하면이 매개 변수를 yes로 설정해야합니다. 새 연결을 통해 이러한 파일에 액세스 할 수 없게됩니다. 클라이언트는 새 연결에서 VC를 제로로 보내지 않으며 Windows 2003은 동일한 IP에서 오는 다른 모든 연결을 종료합니다. 이렇게하면 잠긴 파일에 다시 액세스 할 수 있습니다. 이 옵션을 활성화하면 마스 쿼 레이 딩 라우터 뒤의 연결이 끊어집니다.
편집 :
방금 다른 가능한 해결책을 생각했습니다. 문제의 공유에서 이와 같은 작업을 수행 할 수 있습니다.
veto oplock files = /*.lock/
이것은 .lock 파일의 oplock을 막습니다.
답변
Samba의 매우 영리한 사람들은이 옵션을 제거하기로 결정했으며이를 대체 할 방법은 없습니다.
SMB 호환성에 대해서는 지금까지는 이것이 기본 승리 행동이기 때문에 지금까지.
사용자가 Linux 명령 줄에 익숙하지 않고 열려있는 파일 / 프로세스를 종료하는 방법이 아니라면 SMBD를 다시 시작하거나 서버 자체를 재시작해야합니다.
Samba.org.
답변
비슷한 문제가 발생하여 큰 파일을 복사하는 동안 클라이언트가 충돌하고 재부팅 후 파일이 잠겼습니다. 운 좋게도 이것은 자주 발생하지는 않지만 여전히 삼바 프로세스를 죽여야하는 것은 상당히 성가신 일입니다.
reset on zero vcFedora (27)의 버전 4.7.6에는 여전히 RH가 패치 할 수 있지만 Samba4에서 제거 된 것으로 보입니다. 맨 페이지에서 말했듯이 SMB1 (더 이상 사용해서는 안 됨)에서만 작동하며 SMB2 및 SMB3 연결에서는 아무것도 수행하지 않는다는 점은별로 도움이되지 않습니다.이를 처리하는 유일한 방법 은 마이클에 의해 연결된 스레드 . 나는 제거의 배후에 대한 이론적 근거와 그에 대한 나쁜 점을 모른다reset on zero vc, 나는이 목적을 위해 tcp 타임 아웃을 해킹처럼 사용하는 것을 고려할 것입니다. 어쨌든 합리적인 무언가가 될 수 있습니다.
socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3
이것은 마지막 통신 후 약 40 초 (30 + 3 * 3)의 연결을 끊습니다. 이는 일반적으로 충돌을 감지하고 재부팅하는 데 충분합니다 (서버의 TCP 스택이 클라이언트가 연결을 닫을 수있을만큼 똑똑한 경우) 재부팅 후 해당 keepalive 패킷을 거부합니다).
이렇게하면 네트워크의 부하가 증가하지만 많은 클라이언트에서도 눈에 잘 띄지 않을 것입니다.
답변
다음과 같이 공유별로 oplock을 비활성화 할 수 있습니다.
[acctdata]
oplocks = False
level2 oplocks = False
기본 oplock 유형은 Level1입니다. 레벨 2 oplock은 smb.conf 파일에서 공유별로 활성화됩니다. 또는 공유 내에서 파일별로 oplock을 비활성화 할 수 있습니다.
veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/
Samba의 로그 항목에서 알 수 있듯이 oplocks에 문제가있는 경우이를 안전하게 재생하고 oplocks 및 Level2 oplocks를 비활성화 할 수 있습니다.
커널 Oplock 비활성화 커널 oplocks는 UNIX 프로세스가 캐시 된 파일을 열려고 시도 할 때 Samba에 알리는 smb.conf 매개 변수입니다 (UNIX 커널에 Windows 클라이언트에 oplock 중단을 보내는 기능이있는 경우). 이 매개 변수는 Samba 서버에서 oplocks를 사용하도록 설정하여 UNIX와 Windows간에 파일 공유를 처리합니다. UNIX 프로세스는 Windows 클라이언트에서 Oplocked (캐시) 된 파일을 열 수 있으며 smbd 프로세스는 oplock 중단을 보내지 않습니다. 데이터 손상의 위험이 있습니다. UNIX 커널에 oplock 중단을 보내는 기능이 있으면 커널 oplocks 매개 변수를 사용하여 Samba가 oplock 중단을 보낼 수 있습니다. 커널 oplock은 smb.conf 파일에서 서버별로 활성화됩니다.
kernel oplocks = yes
디폴트는 no입니다.
답변
