Dear Fedora Users,
I’m encountering an issue where I cannot access a Samba shared folder from a Windows 10 guest running on a host configured with virt-manager + QEMU/KVM. Here are the details of the situation:
--> Host Configuration and Status
The Samba shared folder is accessible from the host itself:
$ smbclient //192.168.122.1/intercambio -U x Password for [SAMBA\x]: Try "help" to get a list of possible commands. smb: > ls . D 0 Mon May 31 22:30:19 2021 .. D 0 Mon May 31 22:30:19 2021
This confirms that Samba is running and the share is functional locally.
SELinux is set to permissive mode using:
sudo setenforce 0
However, the problem persists.
The host firewall has the Samba service and port 445 explicitly allowed:
sudo firewall-cmd --add-service=samba --permanent sudo firewall-cmd --reload
--> Guest Configuration and Symptoms
The guest Windows 10 machine can successfully ping the host:
ping 192.168.122.1
However, attempts to connect to the shared folder fail. For example:
Test-NetConnection -ComputerName 192.168.122.1 -Port 445
Output:
WARNING: TCP connect to (192.168.122.1 : 445) failed
ComputerName : 192.168.122.1 RemoteAddress : 192.168.122.1 RemotePort : 445 InterfaceAlias : Ethernet Instance 0 SourceAddress : 192.168.122.155 PingSucceeded : True PingReplyDetails (RTT) : 0 ms TcpTestSucceeded : False
Disabling the Windows Firewall on the guest did not resolve the issue.
--> What I've Tried So Far
Verified Samba functionality locally on the host (smbclient works). Set SELinux to permissive mode (setenforce 0). Ensured the host’s firewall allows Samba traffic. Tested guest-host connectivity (successful ping but failed Test-NetConnection to port 445).
--> Additional Information
Host: Fedora Guest: Windows 10 Virtualization: virt-manager + QEMU/KVM Virtual network: NAT (default virbr0, host IP 192.168.122.1)
--> Request for Assistance
What could be causing the failure to access the Samba shared folder from the Windows guest? Are there specific configurations or troubleshooting steps I should try in this setup?
Any guidance would be greatly appreciated.
Thank you!
Paul
On 1/17/25 5:33 AM, Paul Smith wrote:
Dear Fedora Users,
I’m encountering an issue where I cannot access a Samba shared folder from a Windows 10 guest running on a host configured with virt-manager
- QEMU/KVM. Here are the details of the situation:
--> Host Configuration and Status
The Samba shared folder is accessible from the host itself:
$ smbclient //192.168.122.1/intercambio -U x Password for [SAMBA\x]: Try "help" to get a list of possible commands. smb: > ls . D 0 Mon May 31 22:30:19 2021 .. D 0 Mon May 31 22:30:19 2021
This confirms that Samba is running and the share is functional locally.
SELinux is set to permissive mode using:
sudo setenforce 0
However, the problem persists.
The host firewall has the Samba service and port 445 explicitly allowed:
sudo firewall-cmd --add-service=samba --permanent sudo firewall-cmd --reload
--> Guest Configuration and Symptoms
The guest Windows 10 machine can successfully ping the host:
ping 192.168.122.1
However, attempts to connect to the shared folder fail. For example:
Test-NetConnection -ComputerName 192.168.122.1 -Port 445
Output:
WARNING: TCP connect to (192.168.122.1 : 445) failed
ComputerName : 192.168.122.1 RemoteAddress : 192.168.122.1 RemotePort : 445 InterfaceAlias : Ethernet Instance 0 SourceAddress : 192.168.122.155 PingSucceeded : True PingReplyDetails (RTT) : 0 ms TcpTestSucceeded : False
Disabling the Windows Firewall on the guest did not resolve the issue.
--> What I've Tried So Far
Verified Samba functionality locally on the host (smbclient works). Set SELinux to permissive mode (setenforce 0). Ensured the host’s firewall allows Samba traffic. Tested guest-host connectivity (successful ping but failed Test-NetConnection to port 445).
--> Additional Information
Host: Fedora Guest: Windows 10 Virtualization: virt-manager + QEMU/KVM Virtual network: NAT (default virbr0, host IP 192.168.122.1)
--> Request for Assistance
What could be causing the failure to access the Samba shared folder from the Windows guest? Are there specific configurations or troubleshooting steps I should try in this setup?
Any guidance would be greatly appreciated.
Thank you!
Paul
Hi Paul,
Your troubleshoot is very thorough. I kept scratching my head trying to figure out was was going wrong, then I remembered. Public/private networking on Windows.
M$ has a bizarre way of stating such:
Private: a hazardous environment with lots of potential bad guys on the same network. You are a network island and can see no network resources except your Internet router
Public: you trust everyone on the network.
It is intuitively backwards. Almost every customer I have come across gets it backwards.
The easiest way I know to figure it out is to <win><R> cmd arp -a
If the only computer that show up is you, then you are a network island (private network).
Since every version of Windows is like someone broke into your house and rearranged your furniture, I like to switch to a public network with:
W-Nein: Public / Private network switch from the Registry:
In the registry, first identiry the {xxxx} from [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\
Then switch "catagory" to the type of network you want. For example: if {xxxx} was {162BD447-E88F-4AC3-90B6-0E064CE044E0}
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles{xxxx}] "Category"=dword:00000000 ; 0 = Public ; 1 = Private
You can also look public/private up on the web.
Let us know,
HTH, -T
On 1/18/25 8:00 AM, ToddAndMargo via users wrote:
In the registry, first identiry the {xxxx} from [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\
Then switch "catagory" to the type of network you want. For example: if {xxxx} was {162BD447-E88F-4AC3-90B6-0E064CE044E0}
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles{xxxx}] "Category"=dword:00000000 ; 0 = Public ; 1 = Private
You have to reboot for this to take
On Sat, 2025-01-18 at 08:00 -0800, ToddAndMargo via users wrote:
M$ has a bizarre way of stating such:
Private: a hazardous environment with lots of potential bad guys on the same network. You are a network island and can see no network resources except your Internet router Public: you trust everyone on the network.It is intuitively backwards. Almost every customer I have come across gets it backwards.
I wouldn't be surprised at anything they do, but if I look it up (such as on the link below), I get the kind of thing that I *do* expect.
https://support.microsoft.com/en-au/topic/preventing-smb-traffic-from-latera...
"Guest/Public (untrusted) networks Name: Block outbound Guest/Public SMB 445 Description: Blocks all outbound SMB TCP 445 traffic when on an untrusted network Action: Block the connection..."
"Private/Domain (trusted) networks Name: Allow outbound Domain/Private SMB 445 Description: Allows outbound SMB TCP 445 traffic to only DCs and file servers when on a trusted network Action: Allow the connection if it is secure..."
Which versions of Windows have you discovered have that backwards?
While I could understand some description of private meaning keeping things private, and public as making things public (which I can only ever remember seeing as FTP fileshare descriptions). Everything I've seen has always used private networking for your own space that is secure and can be trusted, whereas being in public is risky and untrusted.
On 1/18/25 11:02 PM, Tim via users wrote:
Which versions of Windows have you discovered have that backwards?
All of them. The problem is the user only see the words "public" and "private". They do not read the description of either as they do not understand such "geek" speak. M$ does adequately describe what each is, but if your do not read the description ...
M$ would remove this misunderstanding if they changed the description to "untrusted" and "trusted"
Tim:
Which versions of Windows have you discovered have that backwards?
ToddAndMargo:
All of them. The problem is the user only see the words "public" and "private". They do not read the description of either as they do not understand such "geek" speak. M$ does adequately describe what each is, but if your do not read the description ...
And is this consistent in describing when you share a resource, and how networking is described?
I haven't touched Windows for eons, likewise played with Samba. When I last used Samba, I still had a Windows 98SE PC.
Looking at my old smb.conf file, I have a shared to everyone folder resource that's sensibly described as being public. I don't recall Win98SE having any such privacy/public options (windows non-security edition).
I had Vista on a laptop. I recall there being the concept of public versus private networks, and that being what I'd expect of trusting that network's connection to anything else, or not, as a whole (in essence, the firewall mode that was applied when using *that* network). But that's the network connection. I don't clearly recall how it described the individual resources that you shared, but in the back of my mind there was some public share (to everyone) kind of thing, which I think was whether a password or logon was required for it.
I have a Mac here, and I've never managed to do well with sharing directories between it and my Linux machines. At times I can get the Mac to access a NFS share on Linux, and that's about it. Not the other way around. And got nowhere trying SMB.
The Mac was reasonably successful at making use of a NAS drive, which I recall I'd configured to use NFS only.
M$ would remove this misunderstanding if they changed the description to "untrusted" and "trusted"
Certainly would be sensible. Therefore it won't happen.
On 1/19/25 2:03 AM, Tim via users wrote:
And is this consistent in describing when you share a resource, and how networking is described?
Superficially, yes. But all kind of stuff pop up to annoy you. And it is not always straight forward.
But far easier than Samba initially. Certainly very different. About the same amount of work in the long run. I just copy over my previous smb.conf file, which I have commented out the wazoo (American slang for plentiful).
Tip: if you are sharing between Windows machines, share on the oldest OS, not the newest. M$ acts like a jerk sharing from a new machine to an older machine.
On 1/19/25 7:05 AM, Earl Ramirez wrote:
And got nowhere trying SMB.I had similar headache with a windows VM on Fedora host and permitting SMB on firewalld libvirt zone resolved the issue
Hi Earl,
I have Windows qemu-kvm virtual machines with my Fedora 41 host Samba (cifs) sharing with all of them. That does not mean yo are not having issues.
If you want it solved, post on the problem, maybe we can collectively figure out the issue for you.
-T
On Sun, 2025-01-19 at 18:29 -0800, ToddAndMargo via users wrote:
Tip: if you are sharing between Windows machines, share on the oldest OS, not the newest. M$ acts like a jerk sharing from a new machine to an older machine.
I always tweaked the parameter that determined who would be master browser to be my Linux server. Having anything that needed rebooting often (Windows), or wasn't there all the time, caused no end of trouble. It's appearance would cause a master browser fight, you could have 15 minutes of no-worky if something transient won that battle, then later disappeared.
That kind of shenanigans, plus the mangling of file permissions, caused me to plump for NFS whereever it was possible.
I sincerely thank everyone who provided feedback - it was incredibly detailed and helpful. In the meantime, I discovered an alternative approach to achieving a shared setup by using:
Windows VirtIO Drivers (https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers)
+
Virtiofs (https://virtio-fs.gitlab.io/)
I followed the instructions outlined in this video:
https://youtu.be/UCy25VFMJCE?list=LL
However, I am now wondering: Would Samba be a more efficient solution?
Best regards,
Paul
On Mon, Jan 20, 2025 at 6:54 AM Tim via users users@lists.fedoraproject.org wrote:
On Sun, 2025-01-19 at 18:29 -0800, ToddAndMargo via users wrote:
Tip: if you are sharing between Windows machines, share on the oldest OS, not the newest. M$ acts like a jerk sharing from a new machine to an older machine.
I always tweaked the parameter that determined who would be master browser to be my Linux server. Having anything that needed rebooting often (Windows), or wasn't there all the time, caused no end of trouble. It's appearance would cause a master browser fight, you could have 15 minutes of no-worky if something transient won that battle, then later disappeared.
That kind of shenanigans, plus the mangling of file permissions, caused me to plump for NFS whereever it was possible.
--
uname -rsvp Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-
Earl Ramirez -
Paul Smith -
Tim -
ToddAndMargo