“53 Network path was not found” when trying to access \fqdn, but \IP works fine
I want to access a windows PC's (192.168.44.1/24, WinXP, lets call it server ;-) ) file share from another PC (192.168.54.110/24, Win 10 Pro, lets call it client).
There is also a MacBook next to the client in 192.168.54.x.
(The WinXP box's only intention is testing SMB access in this lab setup, no production use of course.)
The router/firewall inbetween acts as DNS server at 192.168.54.1.
What works as expected on the client:
ping server
ping server.fqdn
net view \192.168.44.1
Also, I can mount "cifs:\server.fqdn" successfully on the MacBook.
But entering \server.fqdn in Explorer fails, and
net view \server
net view \server.fqdn
both fail with error "53 The network path was not found".
I rule out a DNS problem since ping works with hostname.
I rule out a firewall issue because it works using the IP adress, and because it works on the MacBook.
To me it looks like a client issue.
I have disabled AV/firewall software.
I tried adding server.fqdn to the hosts and LMHOSTS files on client, no success.
Does the server need to be able to resolve client's name via DNS to respond properly? Do I need matching ptr records?
I do not (want to) have a Wins server. Can that be the problem?
windows routing smb netbios
asked Jan 9 at 21:17
PhilipppPhilippp
17316
add a comment |
I want to access a windows PC's (192.168.44.1/24, WinXP, lets call it server ;-) ) file share from another PC (192.168.54.110/24, Win 10 Pro, lets call it client).
There is also a MacBook next to the client in 192.168.54.x.
(The WinXP box's only intention is testing SMB access in this lab setup, no production use of course.)
The router/firewall inbetween acts as DNS server at 192.168.54.1.
What works as expected on the client:
ping server
ping server.fqdn
net view \192.168.44.1
Also, I can mount "cifs:\server.fqdn" successfully on the MacBook.
But entering \server.fqdn in Explorer fails, and
net view \server
net view \server.fqdn
both fail with error "53 The network path was not found".
I rule out a DNS problem since ping works with hostname.
I rule out a firewall issue because it works using the IP adress, and because it works on the MacBook.
To me it looks like a client issue.
I have disabled AV/firewall software.
I tried adding server.fqdn to the hosts and LMHOSTS files on client, no success.
Does the server need to be able to resolve client's name via DNS to respond properly? Do I need matching ptr records?
I do not (want to) have a Wins server. Can that be the problem?
windows routing smb netbios
asked Jan 9 at 21:17
PhilipppPhilippp
17316
2
Does the DNS name match the server's own hostname? Does Wireshark (or another packet capture tool) show the failing command actually making a connection attempt, or does it fail before that?
– grawity
Jan 18 at 9:12
Try to flush a DNS cache on the client.
– montonero
Jan 18 at 9:14
@grawity: No, the hostname of the machine does not match its DNS name - you are right, that might be the problem, I will check! Tcpdump indicates that there is communication between server and client, which seems to be aborted.
– Philippp
Jan 20 at 17:59
add a comment |
I want to access a windows PC's (192.168.44.1/24, WinXP, lets call it server ;-) ) file share from another PC (192.168.54.110/24, Win 10 Pro, lets call it client).
There is also a MacBook next to the client in 192.168.54.x.
(The WinXP box's only intention is testing SMB access in this lab setup, no production use of course.)
The router/firewall inbetween acts as DNS server at 192.168.54.1.
What works as expected on the client:
ping server
ping server.fqdn
net view \192.168.44.1
Also, I can mount "cifs:\server.fqdn" successfully on the MacBook.
But entering \server.fqdn in Explorer fails, and
net view \server
net view \server.fqdn
both fail with error "53 The network path was not found".
I rule out a DNS problem since ping works with hostname.
I rule out a firewall issue because it works using the IP adress, and because it works on the MacBook.
To me it looks like a client issue.
I have disabled AV/firewall software.
I tried adding server.fqdn to the hosts and LMHOSTS files on client, no success.
Does the server need to be able to resolve client's name via DNS to respond properly? Do I need matching ptr records?
I do not (want to) have a Wins server. Can that be the problem?
windows routing smb netbios
asked Jan 9 at 21:17
PhilipppPhilippp
17316
I want to access a windows PC's (192.168.44.1/24, WinXP, lets call it server ;-) ) file share from another PC (192.168.54.110/24, Win 10 Pro, lets call it client).
There is also a MacBook next to the client in 192.168.54.x.
(The WinXP box's only intention is testing SMB access in this lab setup, no production use of course.)
The router/firewall inbetween acts as DNS server at 192.168.54.1.
What works as expected on the client:
ping server
ping server.fqdn
net view \192.168.44.1
Also, I can mount "cifs:\server.fqdn" successfully on the MacBook.
But entering \server.fqdn in Explorer fails, and
net view \server
net view \server.fqdn
both fail with error "53 The network path was not found".
I rule out a DNS problem since ping works with hostname.
I rule out a firewall issue because it works using the IP adress, and because it works on the MacBook.
To me it looks like a client issue.
I have disabled AV/firewall software.
I tried adding server.fqdn to the hosts and LMHOSTS files on client, no success.
Does the server need to be able to resolve client's name via DNS to respond properly? Do I need matching ptr records?
I do not (want to) have a Wins server. Can that be the problem?
windows routing smb netbios
windows routing smb netbios
asked Jan 9 at 21:17
PhilipppPhilippp
17316
asked Jan 9 at 21:17
PhilipppPhilippp
17316
edited Jan 18 at 9:00
Philippp
asked Jan 9 at 21:17
PhilipppPhilippp
17316
asked Jan 9 at 21:17
PhilipppPhilippp
17316
asked Jan 9 at 21:17
PhilipppPhilippp
17316
17316
2
Does the DNS name match the server's own hostname? Does Wireshark (or another packet capture tool) show the failing command actually making a connection attempt, or does it fail before that?
– grawity
Jan 18 at 9:12
Try to flush a DNS cache on the client.
– montonero
Jan 18 at 9:14
@grawity: No, the hostname of the machine does not match its DNS name - you are right, that might be the problem, I will check! Tcpdump indicates that there is communication between server and client, which seems to be aborted.
– Philippp
Jan 20 at 17:59
add a comment |
2
Does the DNS name match the server's own hostname? Does Wireshark (or another packet capture tool) show the failing command actually making a connection attempt, or does it fail before that?
– grawity
Jan 18 at 9:12
Try to flush a DNS cache on the client.
– montonero
Jan 18 at 9:14
@grawity: No, the hostname of the machine does not match its DNS name - you are right, that might be the problem, I will check! Tcpdump indicates that there is communication between server and client, which seems to be aborted.
– Philippp
Jan 20 at 17:59
2
2
Does the DNS name match the server's own hostname? Does Wireshark (or another packet capture tool) show the failing command actually making a connection attempt, or does it fail before that?
– grawity
Jan 18 at 9:12
Does the DNS name match the server's own hostname? Does Wireshark (or another packet capture tool) show the failing command actually making a connection attempt, or does it fail before that?
– grawity
Jan 18 at 9:12
Try to flush a DNS cache on the client.
– montonero
Jan 18 at 9:14
Try to flush a DNS cache on the client.
– montonero
Jan 18 at 9:14
@grawity: No, the hostname of the machine does not match its DNS name - you are right, that might be the problem, I will check! Tcpdump indicates that there is communication between server and client, which seems to be aborted.
– Philippp
Jan 20 at 17:59
@grawity: No, the hostname of the machine does not match its DNS name - you are right, that might be the problem, I will check! Tcpdump indicates that there is communication between server and client, which seems to be aborted.
– Philippp
Jan 20 at 17:59
add a comment |
1 Answer
1
active
oldest
votes
Older Windows systems, which still use NetBIOS Session Layer as the SMB transport, insist on verifying the NetBIOS "Called Name" that the client has provided. They only accept NetBIOS sessions if it matches the server's actual hostname, or is an alias stored in registry, or is a wildcard (if accessing by IP address). This is probably a holdover from the days of NetBIOS-over-IPX and NetBIOS-over-Ethernet.
To disable this checking entirely, add a registry key server-side:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters]
"DisableStrictNameChecking"=dword:00000001
(For modern Windows systems this can be done via Set-SmbServerConfiguration if they even have SMBv1 enabled at all; for XP there's only the manual option.)
This is documented in Microsoft KB940684 and KB3181029. Note that the problem is specific to SMB-over-NetBIOS (port 139), and shouldn't apply to raw SMB-over-TCP (port 445).
It also doesn't apply to SMBv2/3 as those versions appear to use raw TCP exclusively.
answered Jan 20 at 19:52
grawitygrawity
238k37505559
That's it, thanks! Also explains why the Mac behaves differently. Indeed, I have tested with two Win10 boxes in the meantime, and it worked as I had expected (besides needing to adjust Windows Firewall to allow other subnets in for file sharing; however, rdp seems to be allowed per default even from other subnets).
– Philippp
Jan 24 at 9:15
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1392452%2f53-network-path-was-not-found-when-trying-to-access-fqdn-but-ip-works-fin%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Older Windows systems, which still use NetBIOS Session Layer as the SMB transport, insist on verifying the NetBIOS "Called Name" that the client has provided. They only accept NetBIOS sessions if it matches the server's actual hostname, or is an alias stored in registry, or is a wildcard (if accessing by IP address). This is probably a holdover from the days of NetBIOS-over-IPX and NetBIOS-over-Ethernet.
To disable this checking entirely, add a registry key server-side:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters]
"DisableStrictNameChecking"=dword:00000001
(For modern Windows systems this can be done via Set-SmbServerConfiguration if they even have SMBv1 enabled at all; for XP there's only the manual option.)
This is documented in Microsoft KB940684 and KB3181029. Note that the problem is specific to SMB-over-NetBIOS (port 139), and shouldn't apply to raw SMB-over-TCP (port 445).
It also doesn't apply to SMBv2/3 as those versions appear to use raw TCP exclusively.
answered Jan 20 at 19:52
grawitygrawity
238k37505559
That's it, thanks! Also explains why the Mac behaves differently. Indeed, I have tested with two Win10 boxes in the meantime, and it worked as I had expected (besides needing to adjust Windows Firewall to allow other subnets in for file sharing; however, rdp seems to be allowed per default even from other subnets).
– Philippp
Jan 24 at 9:15
add a comment |
Older Windows systems, which still use NetBIOS Session Layer as the SMB transport, insist on verifying the NetBIOS "Called Name" that the client has provided. They only accept NetBIOS sessions if it matches the server's actual hostname, or is an alias stored in registry, or is a wildcard (if accessing by IP address). This is probably a holdover from the days of NetBIOS-over-IPX and NetBIOS-over-Ethernet.
To disable this checking entirely, add a registry key server-side:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters]
"DisableStrictNameChecking"=dword:00000001
(For modern Windows systems this can be done via Set-SmbServerConfiguration if they even have SMBv1 enabled at all; for XP there's only the manual option.)
This is documented in Microsoft KB940684 and KB3181029. Note that the problem is specific to SMB-over-NetBIOS (port 139), and shouldn't apply to raw SMB-over-TCP (port 445).
It also doesn't apply to SMBv2/3 as those versions appear to use raw TCP exclusively.
answered Jan 20 at 19:52
grawitygrawity
238k37505559
That's it, thanks! Also explains why the Mac behaves differently. Indeed, I have tested with two Win10 boxes in the meantime, and it worked as I had expected (besides needing to adjust Windows Firewall to allow other subnets in for file sharing; however, rdp seems to be allowed per default even from other subnets).
– Philippp
Jan 24 at 9:15
add a comment |
Older Windows systems, which still use NetBIOS Session Layer as the SMB transport, insist on verifying the NetBIOS "Called Name" that the client has provided. They only accept NetBIOS sessions if it matches the server's actual hostname, or is an alias stored in registry, or is a wildcard (if accessing by IP address). This is probably a holdover from the days of NetBIOS-over-IPX and NetBIOS-over-Ethernet.
To disable this checking entirely, add a registry key server-side:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters]
"DisableStrictNameChecking"=dword:00000001
(For modern Windows systems this can be done via Set-SmbServerConfiguration if they even have SMBv1 enabled at all; for XP there's only the manual option.)
This is documented in Microsoft KB940684 and KB3181029. Note that the problem is specific to SMB-over-NetBIOS (port 139), and shouldn't apply to raw SMB-over-TCP (port 445).
It also doesn't apply to SMBv2/3 as those versions appear to use raw TCP exclusively.
answered Jan 20 at 19:52
grawitygrawity
238k37505559
Older Windows systems, which still use NetBIOS Session Layer as the SMB transport, insist on verifying the NetBIOS "Called Name" that the client has provided. They only accept NetBIOS sessions if it matches the server's actual hostname, or is an alias stored in registry, or is a wildcard (if accessing by IP address). This is probably a holdover from the days of NetBIOS-over-IPX and NetBIOS-over-Ethernet.
To disable this checking entirely, add a registry key server-side:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters]
"DisableStrictNameChecking"=dword:00000001
(For modern Windows systems this can be done via Set-SmbServerConfiguration if they even have SMBv1 enabled at all; for XP there's only the manual option.)
This is documented in Microsoft KB940684 and KB3181029. Note that the problem is specific to SMB-over-NetBIOS (port 139), and shouldn't apply to raw SMB-over-TCP (port 445).
It also doesn't apply to SMBv2/3 as those versions appear to use raw TCP exclusively.
answered Jan 20 at 19:52
grawitygrawity
238k37505559
edited Jan 20 at 22:16
answered Jan 20 at 19:52
grawitygrawity
238k37505559
answered Jan 20 at 19:52
grawitygrawity
238k37505559
answered Jan 20 at 19:52
grawitygrawity
238k37505559
238k37505559
That's it, thanks! Also explains why the Mac behaves differently. Indeed, I have tested with two Win10 boxes in the meantime, and it worked as I had expected (besides needing to adjust Windows Firewall to allow other subnets in for file sharing; however, rdp seems to be allowed per default even from other subnets).
– Philippp
Jan 24 at 9:15
add a comment |
That's it, thanks! Also explains why the Mac behaves differently. Indeed, I have tested with two Win10 boxes in the meantime, and it worked as I had expected (besides needing to adjust Windows Firewall to allow other subnets in for file sharing; however, rdp seems to be allowed per default even from other subnets).
– Philippp
Jan 24 at 9:15
That's it, thanks! Also explains why the Mac behaves differently. Indeed, I have tested with two Win10 boxes in the meantime, and it worked as I had expected (besides needing to adjust Windows Firewall to allow other subnets in for file sharing; however, rdp seems to be allowed per default even from other subnets).
– Philippp
Jan 24 at 9:15
That's it, thanks! Also explains why the Mac behaves differently. Indeed, I have tested with two Win10 boxes in the meantime, and it worked as I had expected (besides needing to adjust Windows Firewall to allow other subnets in for file sharing; however, rdp seems to be allowed per default even from other subnets).
– Philippp
Jan 24 at 9:15
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1392452%2f53-network-path-was-not-found-when-trying-to-access-fqdn-but-ip-works-fin%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Does the DNS name match the server's own hostname? Does Wireshark (or another packet capture tool) show the failing command actually making a connection attempt, or does it fail before that?
– grawity
Jan 18 at 9:12
Try to flush a DNS cache on the client.
– montonero
Jan 18 at 9:14
@grawity: No, the hostname of the machine does not match its DNS name - you are right, that might be the problem, I will check! Tcpdump indicates that there is communication between server and client, which seems to be aborted.
– Philippp
Jan 20 at 17:59