출처의 증거는 서버 권한과 Android 클라이언트 경로가 서로 별개임을 명확히 보여 줍니다. 새 멤버에게는 명시적으로 읽기 및 쓰기 액세스 권한이 부여되었고, 동일한 공유 폴더가 컴퓨터에서는 정상적으로 작동했습니다. 그러나 Android ZimaClient에서는 앱을 다시 설치한 후에도 두 대의 휴대폰에서 권한 거부가 계속 표시되었습니다.
스레드에서 IceWhale 직원이 문제를 진단한 것은 아니므로, 이것만으로 특정 ZimaClient 버그가 입증되는 것은 아닙니다. 다만 “멤버에게 액세스 권한을 부여하지 않았다”는 설명만으로는 충분하지 않습니다. 현재 ZimaOS는 사용자별 폴더 권한을 공식적으로 지원하므로, 서버 ACL을 변경하기 전에 동일한 자격 증명을 사용해 ZimaClient와 직접 SMB 연결을 비교하여 현재 문제를 재현해야 합니다.
먼저 서버 측 공유 ACL 확인
현재 IceWhale의 다중 사용자 Samba 안내에 따르면 관리자는 공유 폴더에 멤버를 지정하고 읽기 또는 읽기 및 쓰기 권한을 선택해야 합니다.
현재 ZimaOS 멤버 공유 설정 절차를 사용하세요.
PC 테스트를 통해 멤버 자격 증명이 작동할 수 있음을 확인
작성자는 컴퓨터에서 공유 폴더에 액세스할 수 있었다고 말했습니다. 이는 사용자, 계정 및 공유 폴더가 적어도 하나의 클라이언트 경로에서는 정상적으로 작동할 수 있음을 보여 주므로, 이 스레드에서 가장 유용한 분리 테스트입니다.
두 대의 Android 휴대폰에서 실패하면 단일 앱 설치 손상 가능성은 낮아짐
사용자는 ZimaClient를 다시 설치했고 다른 휴대폰에서도 테스트했습니다. 두 휴대폰 모두 여전히 권한 거부를 반환했습니다. 따라서 단일 휴대폰의 캐시 손상 가능성은 낮아지지만, 실제 모바일 인증 실패 원인이 무엇인지는 확인되지 않습니다.
Android에서 직접 SMB 테스트
커뮤니티 답변에서는 일반 Android SMB 클라이언트를 사용해 동일한 사용자 이름과 비밀번호로 테스트할 것을 제안했습니다. 직접 SMB 연결은 성공하지만 ZimaClient만 실패한다면, Samba ACL보다는 ZimaClient의 세션 계층에 문제가 있을 가능성이 더욱 높습니다.
두 방식 모두 실패한다면 정확한 SMB 자격 증명, 사용자 이름 형식, 특수 문자 및 서버 측 계정 상태를 검토하세요.
기존 ZimaClient 세션을 완전히 종료
멤버 권한을 변경해도 이미 인증된 클라이언트 세션에는 즉시 반영되지 않을 수 있습니다. 로그아웃하고, 현재 클라이언트에서 필요한 경우 저장된 기기 또는 세션을 삭제한 다음 다시 연결하여 동일한 공유 폴더를 재테스트하세요.
최신 ZimaOS 및 ZimaClient에서 재테스트
출처의 환경은 ZimaOS 1.6.1이었습니다. 이후 최신 ZimaOS와 모바일 클라이언트는 변경되었습니다. 현재 ZimaOS 문서에서는 권한이 ZimaOS 계정에 연결되며 ZimaClient가 로컬 및 원격 액세스를 제공한다고 설명합니다.
이후 발생한 모바일 연결 끊김은 별개의 증상
작성자는 이후 휴대폰 백업은 작동했지만 모바일 연결이 자주 끊겼다고 말했습니다. 이 스레드에서는 이것이 동일한 권한 문제인지, 네트워크 또는 P2P 문제인지, 아니면 또 다른 클라이언트 회귀 문제인지 확인되지 않았습니다.
로그에서 공통 원인이 확인되지 않는 한 “권한 거부”와 “연결 끊김”을 별도의 테스트 사례로 다루세요.
Android 멤버 액세스 FAQ
출처에서 멤버 권한이 실제로 구성된 것이 확인되었나요?
예. 스크린샷에 멤버와 폴더에 읽기 및 쓰기 액세스 권한이 부여된 모습이 표시되어 있습니다.
컴퓨터에서 해당 폴더가 작동했나요?
예. 따라서 출처의 증거는 기본적인 공유 ACL 설정 오류일 가능성이 낮음을 보여 줍니다.
스레드에서 IceWhale의 해결 방법이 확인되었나요?
아니요. Android 문제는 해결되지 않은 상태로 끝났습니다.
