유닉스 권한(및 SMB 공유의 영향)

유닉스 권한(및 SMB 공유의 영향)

몇 년 전(Linux 시스템을 사용할 때) 일부 파일을 복사하여 NFS 공유로 마운트한 NAS가 있습니다.

몇 년 후... 며칠 전 SMB를 통해 Windows 컴퓨터에서 동일한 파일/폴더에 액세스하려고 했습니다. 결과: 허가가 거부되었습니다. 접근, 이동, 삭제 등 아무것도 할 수 없습니다. 관리자 권한이 있어도. Mac 컴퓨터(여전히 SMB 사용)에서 액세스를 시도했는데 Unix 엔진이라고 확신했습니다...같은 결과였습니다. 뿌리가 있어도.

그런 다음 Linux(여전히 SMB 사용)에서 시도해 보았지만 다시 동일한 결과를 얻었습니다. 그런 다음 NFS 마운트로 전환했고 이제 아무런 문제 없이 전체 액세스 권한을 갖게 되었습니다.

원인을 조사해 보았지만 여전히 단서는 없습니다.

예제 폴더의 복사본을 몇 개 만들었습니다.

여기에 이미지 설명을 입력하세요.

STUDY원본: 확장된 속성이 있다는 점에 유의하세요. SMB를 사용하여 관리할 수 있는 다른 모든 파일과 폴더에는 확장된 속성이 없기 때문에 이것이 문제인 것 같습니다.

그래서 제가 가장 먼저 한 일은 "STUDYtest"라는 복사본을 만들고 다음을 사용하여 속성을 제거하는 것이었습니다.

sudo setfacl -Rbk STUDYtest/

실제로 위의 스크린샷에서 볼 수 있듯이 확장된 속성을 제거하지만 그 안에 있는 폴더와 파일은 여전히 ​​SMB를 통해 관리할 수 없습니다(이 과정에서 다른 사람의 쓰기도 손실됩니다). 묻지 마세요. 나 왜!).

그런 다음 다음을 사용하여 속성을 유지하지 않고 폴더를 다른 위치로 복사하려고했습니다.

cp -r --no-preserve=mode,ownership STUDY/ /home/alberto/

그런 다음 이름을 바꾸고 STUDYnopreserve다시 NAS에 복사했는데 이번에는 Windows에서 SMB를 통해 관리할 수 있었습니다.

왜인지 이해가 안 돼요! 나에게 그들은 똑같아 보인다:

여기에 이미지 설명을 입력하세요.

여기에 이미지 설명을 입력하세요.

둘 다 확장 속성을 가지고 있는데 유일한 차이점은 소유자입니까?

모든 데이터(3TB 이상)를 다른 곳으로 복사하고 반환하는 것을 피하고 싶고, 가장 중요한 것은 그 이유를 이해하고 싶습니다.

누군가 나에게 올바른 방향을 알려주거나 다음 테스트를 제안할 수 있나요?

답변1

추가 테스트를 수행한 결과 이전 해결 방법이 완전히 작동하려면 no-preserve다른 위치/드라이브에 복사본(옵션 포함)을 만든 다음 원래 위치/드라이브(데이터를 동일하게 유지해야 하는 경우)로 다시 만들어야 한다는 사실을 발견했습니다. 위치). 그렇지 않으면 콘텐츠에 액세스할 수 있지만 원격 SMB 사용자는 콘텐츠를 수정하거나 삭제할 수 없습니다.

나는 그 동안 내가 생각했던 최종 해결책을 찾았고 이전에 시도했던 그 어떤 것보다 훨씬 간단했기 때문에 더 이상 원인을 조사하지 않았습니다.

간단히:

sudo chmod -R 777 /path

관련 정보