집에 작은 네트워크가 있고 Windows에 공유 폴더가 있습니다. 다른 Windows 컴퓨터에서는 Windows 공유 목록을 볼 수 있지만 Linux 장치에서는 이 작업을 수행할 수 없습니다.
"Windows 공유"를 클릭하면노틸러스보여주다:
Failed to retrieve share list from server: No such file or directory
그런데 놀랍게도 접속이 가능해요smb://192.168.1.2/SharedFolder
나는 테스트했다페도라 23 라이브,더반 8그리고데비안 테스트모든 것이 동일합니다.
포트 136, 137, 138 및 445가 열려 있는지도 확인했습니다.
답변1
초기 WannaCry 맬웨어 감염 이후 Microsoft는 원래 계획보다 더 빠르게 Windows 디스크 및 프린터 공유 프로토콜 SMB 1.0의 이전 버전을 더 이상 사용하지 않기 시작했습니다.
불행하게도 Windows 시스템이 Active Directory가 아닌 도메인에서 네트워크 공유를 검색하고 찾아보는 전통적인 방법은 여전히 이전 프로토콜의 일부를 사용합니다.
비 AD 네트워크를 위한 새로운 Windows 공유 검색 프로토콜 WS-Discovery,SMB 프로토콜과 완전히 별개로 Samba는 아직 이에 대한 지원을 통합하지 않았습니다.
Windows 시스템에 SMB 1.0이 비활성화되어 있고(보안상의 이유로 강력히 권장됨) Active Directory를 사용하고 있지 않으며 Linux 시스템에 새 프로토콜을 사용하여 사용 가능한 공유를 알릴 수 있는 소프트웨어가 없는 경우 Windows 시스템은 SMB 1.0을 사용할 수 있습니다. Linux 공유는 자동으로 발견되지만 사용자가 공유 호스트의 이름/IP 및 공유 이름을 알고 있는 경우에는 계속 연결할 수 있습니다.
Samba가 새 프로토콜을 성공적으로 통합할 때까지 이 문제를 완화하기 위한 몇 가지 프로젝트가 있습니다.
https://github.com/christgau/wsdd- WS-Discovery 응답자의 Python 3 스크립트 구현입니다.
https://github.com/Andy2244/wsdd2그리고https://github.com/kochinc/wsdd2- Netgear ReadyNAS OS 6의 오픈 소스 코드를 기반으로 하는 다양한 버전의 C 구현.
그들은 Samba의 구성을 읽고 로컬 네트워크의 WS-Discovery 쿼리에 응답합니다. 이를 사용하려면 포트 5357에서 들어오는 TCP 연결을 허용하고 포트 3702에서 멀티캐스트(UDP) 트래픽을 허용해야 합니다. 프로토콜의 멀티캐스트 부분은 IPv4 멀티캐스트 주소 239.255.255.250과 IPv6 멀티캐스트 주소 fe02::c를 사용합니다.
클라이언트 측에서 Debian 8은 클라이언트 도구에 새로운 검색 프로토콜을 포함하기에는 너무 오래되었을 수 있습니다.
답변2
[ipcs] 암시적 공유 권한이 게스트를 허용하는지 확인하세요.
편집: "서버" 시스템은 Windows 시스템이므로 Windows 클라이언트의 기본 동작은 현재 자격 증명을 사용하여 서버에 로그인을 시도하는 것임을 지적하고 싶습니다. 그래도 작동하지 않으면 사용자에게 대안을 묻는 메시지를 표시합니다. Windows 시스템의 IPC$ 공유는 다른 공유 개체 목록을 얻는 데 사용되는 공유이기 때문에 게스트(즉, 익명) 액세스를 허용해야 합니다. 따라서 먼저 Windows 시스템의 IPC$에 실제로 익명으로 액세스할 수 있는지 확인하십시오. 아무 것도 작동하지 않으면 Linux 시스템의 터미널에서 "smbclient -L 192.168.1.2"를 시도하고 프롬프트에서 Enter 키를 누르십시오. 이것~해야 한다모든 것이 올바르게 구성되면 작동합니다. 그렇지 않으면 운이 좋지 않아 Windows 클라이언트의 사용자 계정이 "서버"의 (일부) 계정과 동일하게 구성됩니다.
답변3
이 문제가 발생하여 패키지를 설치하여 해결했습니다 gvfs-bin
. , , 및 를 제외한 대부분 gvfs-bin
의 gvfs
패키지가 설치됩니다 .gvfs
-common
-libs
-daemons
-backends