새 ZimaOS 사용자는 보호되지 않은 게스트 계정을 추가했을 때만 Windows 파일 탐색기에서 Samba 공유로 파일을 복사할 수 있었습니다. 게스트 액세스를 제거하자 Windows는 공유에 액세스할 수 없다고 표시했으며, 새 사용자 이름과 비밀번호를 묻는 창도 표시하지 않았습니다.
게스트 액세스를 활성화한 상태로 두지 않고 문제를 해결했습니다. Zima 팀원 Giorgio는 사용자에게 Windows에 저장된 모든 자격 증명을 삭제한 다음 커뮤니티 Samba 연결 스크립트를 다시 실행하도록 안내했습니다. 작성자는 이렇게 하자 충돌이 해결되고 액세스가 복원되었다고 확인했습니다.
기존 ZimaOS 및 Windows 설정
사용자는 ASUS Prime N100I-D D4 시스템에 ZimaOS 1.4.1을 설치했습니다. Crucial 500GB M.2 SSD에는 운영 체제가 설치되어 있었고, Seagate 1TB 하드 드라이브 하나는 ZimaOS 웹 인터페이스를 통해 공유 드라이브로 노출되어 있었습니다.
게스트 사용자를 활성화한 상태에서는 ZimaOS의 공유 관리에서 공유 URL을 복사해 Windows 파일 탐색기에 붙여넣으면 정상적으로 작동했습니다. 혼란스러웠던 점은 게스트 사용자가 해당 공유에 지정되어 있지 않았는데도 다른 비밀번호 보호 공유에도 액세스할 수 있는 것처럼 표시되었다는 것입니다.
처음 시도한 자격 증명이 도움이 되지 않았던 이유
작성자는 자격 증명 문제라고 생각해 Windows 자격 증명 관리자에 항목을 직접 추가했습니다. 또한 ZimaOS SMB 도움말 페이지와 커뮤니티의 명령줄 연결 튜토리얼도 따랐습니다. 스크립트는 자격 증명을 요청했지만, 예상한 ZimaOS 사용자 이름과 비밀번호를 입력해도 처음에는 공유가 열리지 않았습니다.
관련 가능성이 있는 세부 사항은 동일한 서버와 IP 주소에서 이전에 TrueNAS를 실행했다는 점이었습니다. 이전 설치가 충돌을 일으켰다는 사실이 스레드에서 입증된 것은 아니지만, 문제를 진단할 당시 Windows에는 웹 자격 증명과 Windows 자격 증명이 여러 개 저장되어 있었습니다.
확인된 해결 방법: 먼저 저장된 자격 증명 모두 제거
Giorgio가 안내한 순서는 Windows 제어판에서 저장된 자격 증명을 모두 제거하고, 필요한 경우 공유를 다시 만든 다음 ZimaOS Samba 명령줄 연결 튜토리얼을 다시 실행하는 것이었습니다. 작성자는 웹 자격 증명과 Windows 자격 증명을 모두 삭제하고 해당 튜토리얼의 배치 파일을 다시 실행한 뒤, 마침내 보호된 공유에 액세스할 수 있었다고 확인했습니다.
이 결과가 중요한 이유는 이 경우 게스트 활성화가 임시 해결책에 불과했기 때문입니다. 성공한 방법은 다시 인증하기 전에 Windows가 충돌을 일으키는 자격 증명 상태를 잊도록 하는 것이었습니다.
Zima Client 화면
다른 커뮤니티 회원은 정상적으로 매핑된 드라이브 설정에서 예상되는 Zima Client와 Windows 11 화면을 공유했습니다. 이 스크린샷은 작성자의 자격 증명 충돌을 해결한 방법은 아니지만, 다운로드 가능한 클라이언트와 별도의 CLI 튜토리얼을 구분하는 데 도움이 되었습니다.
FAQ
이 사용자는 게스트 액세스를 계속 활성화해야 했나요?
아니요. 게스트 액세스를 사용하면 공유에 일시적으로 연결할 수 있었지만, 확인된 해결 방법은 저장된 Windows 자격 증명을 모두 제거한 후 보호된 계정으로 다시 연결하는 것이었습니다.
자격 증명 하나를 직접 추가하면 문제가 해결되었나요?
아니요. 작성자는 이미 자격 증명을 직접 추가해 보았습니다. 성공한 시도는 저장된 웹 자격 증명과 Windows 자격 증명을 모두 삭제한 후 연결 스크립트를 다시 실행했을 때 이루어졌습니다.
