서비스 마이그레이션 후 신비한 Samba 권한 실패

maildir 네트워크 공유(CIFS)를 새 스토리지 서버로 마이그레이션한 후 파일 권한 문제가 발생하기 시작했습니다(사용자는 기존 메일을 삭제할 수 없었습니다). 내 IMAP 서비스는 Dovecot이지만 해당 서비스보다 낮은 수준에서 문제를 식별할 수 있습니다.

root이 문제 는 파일을 호스팅하는 서버와 파일이 설치된 서버(이하 "클라이언트"라고 함)의 메일 디렉터리로 이동하여 다음 동작을 경험/관찰할 수 있기 때문에 나타납니다.

• ls두 컴퓨터 모두에 동일한 파일 목록과 권한을 표시합니다.
• 마이그레이션 이후 권한이 정확히 일치하지 않지만 권한 변경은 동작에 영향을 미치지 않습니다. (모든 후속 작업은 권한이 있는 파일에서 수행됩니다 -rw-rw---- 1 mail mail.)
• mailnot 대신 as 작업을 수행해 도 root아무런 효과가 없습니다.

• 다음과 같이 권한을 변경해 보세요 chmod g-rw *.

  • 서버에서는 잘 작동합니다
  • 마이그레이션 후 생성된 파일에 대해 클라이언트에서 제대로 작동합니다.

  • 클라이언트의 사전 마이그레이션 파일에서 다음 오류가 발생합니다.

    chmod: "1479603582.M874812P11259.Pantheon,S=84750,W=85933:2,Sa"에 대한 권한 변경: 잘못된 인수

• 파일을 읽어보세요:
  • 서버에서는 잘 작동합니다
  • 클라이언트 파일 이름 자동 완성 및 vim 보고Permission Denied

이전 파일에 영향을 줄 수 있는 ACL을 찾으면 서버에 다음과 같은 출력이 표시됩니다.

root@<storage-server>:/<path-to-share>/<site>/<user>/folders/cur# getfacl <filename>
# file: <filename>
# owner: mail
# group: mail
user::rw-
group::rw-
other::---

getfattr아무것도 출력되지 않습니다.

스토리지 서버는 이전에 ZFS 스토리지 풀에서 CIFS 서비스를 사용하는 Solaris+debian 기반의 오래된 소프트웨어 운영 체제(Nexenta)였습니다. 이제 Ubuntu 16.04에서 다시 ZFS 스토리지 풀의 CIFS 서비스를 사용합니다. 모든 경우에 ACL은 지원되지만 어느 곳에서도 사용되지 않습니다.

내 Samba 공유 구성:

[Maildir]
    path = /<path-to-share>
    browseable = no
    guest ok = no
    valid users = mail
    writable = yes
    create mode = 0660
    directory mode = 0770

//<host>/Maildir /var/mail cifs auto,credentials=/root/.smb_mail,user,rw,exec 0 0파일 시스템과 해당 상위 시스템의 모든 zfs 등록 정보는 기본값을 갖습니다 .

생성 모드/디렉터리 모드를 제거하고 유효한 사용자에게 @mail을 추가하려고 시도했지만 둘 다 작동하지 않았습니다.

내 권한이 어떻게 잘못될 수 있나요?

고쳐 쓰다:

NFS 공유로 전환을 시도했는데,문제는 여전히 존재합니다. maildir 내용을 사용하여 새 위치(다른 새 파일 시스템)에 복사해 보았지만 cp -r완전히 chown -r mail:mail다른 경로에서 제공되는 동안 여전히 존재합니다.

마침내 나는 그것을 시도했지만 mv somefile backup && rm somefile && cat backup > somefile && chown mail:mail somefile권한이 거부되어 파일을 읽으려는 시도가 여전히 실패했습니다.

공유 메커니즘, 논리적 위치, Unix 권한/소유권 또는 모든 형태의 파일 메타데이터와 독립적인 방식으로 특정 파일에 대한 작업을 방지하는 방법을 모르겠습니다.

업데이트 2:

NFS 공유로 다시 전환을 시도했는데 이번에는 권한 문제가 사라졌습니다. 하지만 NFS로 전환하면 다른 문제, 특히 부팅 문제가 발생할 수 있으므로 전환하고 싶지 않습니다. 문제는 확실히 삼바에 있지만 모든 작동 데이터(다양한 .tdb 및 .dat 파일 등)를 지워도 도움이 되지 않습니다.

업데이트 3:

문제는 콜론이 포함된 파일 이름으로 범위가 좁혀졌습니다. 콜론을 제거하기 위해 파일 이름을 바꾸면 클라이언트에서 읽을 수 있게 되고, 콜론이 포함된 원래 이름으로 이름을 바꾸면 읽을 수 없게 됩니다. 시간이 지남에 따라 Dovecot은 특정 정보를 추적하기 위해 파일 이름을 바꾸고 콜론을 추가하여 결국 모든 메시지를 읽거나 쓸 수 없게 만드는 것처럼 보이지만 이전에도 이런 일이 발생했습니다.

몇 가지 추가 관찰 사항: 콜론을 사용하여 파일을 만들고 읽는 것은 클라이언트에서 작동합니다(콜론은 서버에서 큰따옴표로 나타납니다). 그런데, 이것이 처음에 콜론이 있는 파일 이름을 얻는 방법입니다... 최신 파일에는 콜론이 2개 있는 것처럼 보이지만 서버에는 큰따옴표와 콜론이 있는 것으로 표시됩니다.

일종의 코딩 문제처럼 보이기 시작했습니다. 특히 두 시스템이 처음으로 동종이기 때문에 이상합니다.