클라이언트가 연결을 끊은 후 Samba가 파일 잠금을 보유하지 못하게하는 방법은 무엇입니까?


11

여기에는 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 서버에서 파일 잠금을 사용하지 않도록 설정 해야하는 이유 있기 때문에 파일 잠금을 사용하지 않도록 설정하고 싶습니다 .

답변:


11

아래 단계를 통해 여러 가지 상황 에서이 정확한 문제를 해결하는 데 도움이되었습니다.

  1. samba 서버에 로그인하십시오.
  2. "smbstatus"를 실행하십시오.
  3. 출력의 세 번째 섹션에서 파일에 잠금이있는 프로세스의 pid를 찾으십시오.
  4. smbstatus 출력의 첫 번째 및 두 번째 섹션에서 예상되는 사용자 및 호스트 이름과 일치하는지 확인하십시오.
  5. "ps -ef"를 실행하고 해당 pid가있는 smbd가 얼마나 오래 실행되었는지 확인하십시오.
  6. 컴퓨터를 마지막으로 다시 부팅하기 전부터 실행 중이었다면 smbd가 남았습니다. 단지 하나의 smbd를 죽여라. (그리고 올바른 것을 얻으십시오-부모 pid가 1이 아닌 것이어야합니다.)

또한 일부 smbd pids가 몇 시간 동안 실행되었고 이들이 잠근 파일이 필요한 파일임을 알 수 있습니다. 위와 같이 이러한 프로세스를 종료하면 괜찮을 것입니다. 실수로 주 smbd 프로세스를 종료 한 경우 다음 명령을 사용하여 프로세스를 다시 시작할 수 있습니다. sudo /etc/init.d/smbd restart
Socceroos

5

살펴보십시오 :

reset on zero vc = yes / no

문제가 해결되는지 확인하십시오.

로부터 smb.conf매뉴얼 페이지

이 부울 옵션은 들어오는 세션 설정이 동일한 IP에서 오는 다른 연결을 종료해야하는지 여부를 제어합니다. 이것은 기본 Windows 2003 동작과 일치합니다. 비정상적인 네트워크가 있고 이전 연결에 여전히 공유 모드가있는 파일이있는 동안 Windows가 다시 연결하기로 결정하면이 매개 변수를 yes로 설정해야합니다. 새 연결을 통해 이러한 파일에 액세스 할 수 없게됩니다. 클라이언트는 새 연결에서 VC를 제로로 보내지 않으며 Windows 2003은 동일한 IP에서 오는 다른 모든 연결을 종료합니다. 이렇게하면 잠긴 파일에 다시 액세스 할 수 있습니다. 이 옵션을 활성화하면 마스 쿼 레이 딩 라우터 뒤의 연결이 끊어집니다.

편집 :
방금 다른 가능한 해결책을 생각했습니다. 문제의 공유에서 이와 같은 작업을 수행 할 수 있습니다.

veto oplock files = /*.lock/

이것은 .lock 파일의 oplock을 막습니다.


0

Samba의 매우 영리한 사람들은이 옵션을 제거하기로 결정했으며이를 대체 할 방법은 없습니다.

SMB 호환성에 대해서는 지금까지는 이것이 기본 승리 행동이기 때문에 지금까지.

사용자가 Linux 명령 줄에 익숙하지 않고 열려있는 파일 / 프로세스를 종료하는 방법이 아니라면 SMBD를 다시 시작하거나 서버 자체를 재시작해야합니다.

Samba.org.


이에 대한 인용이 있습니까?
BE77Y

몇 가지를 살펴 봐야하지만 list.samba.org/archive/samba-technical/2011-July/078621.html (생각하지 말라고 주장하는 사고 과정과 챕터 표시) .samba.org / archive / samba-technical / 2008-October /… (매개 변수가 4.0에서 제거되었음을 나타냅니다)
Michael

2019 년 현재, Debian 9-Samba 4.5.12에서는 reset on zero vc옵션이 여전히 설명서에 나열되어 있으며으로 표시됩니다 testparm. 다시 돌아 왔거나 실제로 제거되지 않았습니다.
mivk 2016 년

0

비슷한 문제가 발생하여 큰 파일을 복사하는 동안 클라이언트가 충돌하고 재부팅 후 파일이 잠겼습니다. 운 좋게도 이것은 자주 발생하지는 않지만 여전히 삼바 프로세스를 죽여야하는 것은 상당히 성가신 일입니다. 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 패킷을 거부합니다).

이렇게하면 네트워크의 부하가 증가하지만 많은 클라이언트에서도 눈에 잘 띄지 않을 것입니다.


이것이 기괴한 Windows10 클라이언트 "nobody nogroup"좀비 스레드 문제에 도움이되는지 알고 있습니까? 여러 사이트에있는 많은 Windows10 클라이언트가 처리기 프로세스가 종료 / 종료 될 때까지 "nobody nogroup"에 할당되는 수백 (종종 수천)의 좀비 스레드를 남기기 시작했습니다. 일반적으로 설정을 지정 deadtime = 10하면 지워지지 만 SMB3_11 연결에서 파일 잠금이 영원히 남아 있으면 PID의 파일 잠금이 여전히 존재하는 동안 데드 타임이 확인되지 않으므로 아무런 영향을 미치지 않습니다. 매우 실망스러운.
zxq9

당신이 묘사 한 문제에 대해 들어 본 적이 없습니다. deadtime클라이언트가 파일을 연 경우 아무 것도 수행하지 않으므로 질문은 파일을 열어 두는 것입니다. 그러나 그것은 아마도 여기에서 논의 된 것과는 완전히 다른 문제 일 것이므로 새로운 질문을 열어야합니다. 내 socket options제안은 제대로 닫혀 있지 않습니다 연결을 할 수 있지만 (클라이언트 충돌, 네트워크 중단 등으로 인해) 아마 당신의 WX 클라이언트는 어떤 (추가 조치 또는 익명 세션의 어떤 종류를 사용하지 않고 서버에 연결하는 경우 nobody.nogroup제안 ).
Jakob

이 문제에 대한 한 가지 질문 이 있지만 실제 해결책은 없습니다. 최신 버전에서 수정 될 수있는 삼바 문제 일 수 있습니다.
Jakob

메일 링리스트에는 이것에 대한 언급이 꽤 있으며, 실제 솔루션은 어디에도 없으며 내가 시도한 버전 (현재 분기는 4.9)이 문제를 해결하지 않습니다. Windows10 클라이언트에만 있습니다. nobody : nogroup은 게스트가 전 세계적으로 비활성화되어 공유를 허용하지 않기 때문에 당황스럽고 nobody 항목의 PID는 항상 유효한 사용자 이름을 가진 단일 유효한 항목과 동일합니다. 따라서 12345 someuser somegroup...하나의 항목에 800 개의 12345 nobody nogroup ...항목이 있지만 소수의 파일 잠금 (800이 아님) 만 표시됩니다. 엄청 이상해. 내 클라이언트 사이트 중 3 개에 영향을줍니다.
zxq9

이것은 활동이 많은 사이트에서만 리소스 제약이되므로 관심이 거의없는 것 같습니다. 대부분 의 경우 문제가 없으므로 사람들은 그 사실을 알지 못하며 클라이언트가 실제로 연결을 닫을 때마다 스스로를 정리합니다.
zxq9

0

다음과 같이 공유별로 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입니다.

출처

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.