Discussion in 'Networking & NAS' started by liamthefirst, Aug 2, 2016.
if im honest i sort of understand what your saying but not sure how i would check any of this info
so i have done what "Rossmartin" said and wired into the gig switch and i now have my mapped drives back where do i go from here
The workgroup is change by opening the file explorer, right click "This PC" and select properties. In the "Computer name, domain and workgroup settings click on "Change settings" You need to have admin permissions for this. In the "System Properties" window under the "Computer Name" tab click on Change next to "To rename this computer or change its domain or workgroup, click Change"
For what you describe it seems that there is some misconfiguration on the network settings.
You need to login into the Router as the admin and change the settings. The router should have a web interface to change its settings. It is best to modify this using a wired connection to the router. You need to know what the IP address of the router is, the admin user name and its password. Type the IP address of router in a browser and login with the admin details.
In the configuration settings there are some entries which can configure the IP range the DHCP of the router will give to your devices. You will need to check that your servers IP addresses it is just outside the range you laptop, phone, TV and any other device use when they connect.
There should also be some entries that will allow you to reserve an IP address for a particular device. For this you will need to know the mac address of your servers and reserve their IP addresses. This warranty that whenever this devices join the LAN they always get the same IP address.
It may also have an entry for the workgroup of the LAN.
I'd advise NOT to do this. Reserved DHCP addressing was designed for very specific usage scenarios with diskless workstations. It's far better to use static addressing on each static device.
Log into each static device (router, switch, sky box, synology boxes, dune boxEs, etc) and note their IP address.
The router will be something like 192.168.1.254 (am on iPad so cannot easily view the details you screenshot), and a subnet mask of 255.255.255.0 you don't need to know about the mask, just that each device must have a unique IP address, but the SAME subnet mask.
Login to the router as admin, navigate to the LAN section, or wherever DHCP is configured. Change the range of addresses (commonly referred to as a 'pool') from the default (often 192.168.1.1 to .1.253) to the range 192.168.1.64 to .1.253). Obviously, if your router uses a different number (I'd .0.254 then change to .0.64). Save the changes. FWIW, I prefer to have my router set to .1
At this point, check your own IP address, to check its not about to conflict with anything... Open a dos prompt and type ipconfig. If it falls outside the range .1.64 - .1.253, just type ipconfig /release then ipconfig /renew
Log into each static device in turn and change the IP address configuration to 'manual' - might be called static - and assign each device a static IP address, starting from .1.2 (in this case, I'd assign that to the switch), the synology boxes .5 and .6, the media boxes .10 and .11, the sky box .15
Whilst you are in the switch, check that it is not acting as a DHCP server, if it is, disable it.
Each device should have the subnet mask of 255.255.255.0
Each device should have the default gateway set to the IP address of the router
For DNS, use either the router IP address, or your preferred DNS resolver (I use google, 184.108.40.206 and 220.127.116.11 as the primary and secondary. You can always set the secondary to the routers IP address)
You could just use .2, .3 and so on, but if you add another switch or synology, you can group like devices sequentially.
double check everything, delete the synology drive mappings on the Windows 10 laptop, then reboot everything on device at a time, starting with the router. This ensures everything. Comes up cleanly, has a new IP address, and that the address tables in each device (which keep a map of what device/IP address they have learnt) is wiped and will be relearned. This is especially true for the switch.
Recreate the drive mappings on the laptop.
Having tapped that out on the iPad, I'm not convinced it's an IP addressing issue anyway, but if the underlying network addressing is sound it's a start.
Out of interest, when you lose connectivity to the media boxes, do you lose connectivity to anything else, e.g. Internet?
Does it happen when connected by wired, wireless, or both! If wired, AND you lose connectivityfull stop, replace the laptops network cable.
I suspect the issue might be one that has been alluded to before; and it could be one of two reasons. Edit: try option 2 first.
1. there have been changes to the network stack in Windows 10 (it used SMB3.1, and a rcentish patch changed this to 3.11 which Samba 4.2 - the Linux version of SMB doesn't fully support... nor does/do older Windows clients). If this is the case, you'll need to change Windows 10 to use SMB1 (spit) as SMB 2 and 3 share the same protocol stack
https://support.microsoft.com/en-us/kb/2696547 shows how.
2. Windows 10 deletes and recreates network shares in the background, to conserve resources (!!!! Go figure). Open a cmd prompt as admin, and type
net config server /autodisconnect:-1
I guess we all have different opinions. I'd advise to do it because it simply fits the bill and unless one knows networking very well it solves many problems that configuring manually brings to the table. For all intent and purpose it will behave like an static IP and no need to do all the configuring that can tricky for most users.
FYI - the OP PM'd me an IPCONFIG - it all looks fine, G/W, DNS and DHCP servers are all pointing to the same device which one presumes is his router at 192.168.0.1. However, this doesn't look like an IP addressing issue to me. It looks more like either a firewall issue or some drive handles/security (as in credentials, SID's, etc.) nastiness. Presumably the Synology NAS's are using some form of *NIX and as we know *NIX is fussy about case sensitivity (e.g. names, loginids, passwords, etc) where Windows is not.
FWIW - I'm Win10 and didn't encounter any issues when transitioning from Win7 - my media server is Linux based HP micorserver (no idea which version of SMB) - it all worked fine - I'm not using any (old school) drive handles, normal URL's seem to be working fine and I can browse for the shares without issue.
I guess it may be worth establishing whether he's using SMB (versus NFS) shares just to rule that out.
Its not so much opinion, but using the tool as it was designed for and the advantages it delivers, borrowing from enterprise best practice.
If you have a consistent approach to addressing, then when trying to troubleshoot why something doesn't work you don't need to constantly check on what device has what address, reconfigure the network, or spend time in the DHCP server.
Reserved addressing was designed for diskless workstations that needed a static IP address, for example an application that would only respond to IP addresses in a given range, and it is obviously impossible to assign a static address to a diskless client.
I'd have to disagree that manual configuration of a client is any "trickier" than using a reserved address; I'd argue that it is easier; both require configuring the DHCP server. One then accesses the client, and enters a set of numbers; address, mask, gateway, and DNS. Compare that to trying to instruct a novice how to extract a hexadecimal MAC address and enter that into a router, assign an IP address, and do it for each static device on their network.
I'm not arguing that it doesn't work, it's simply 'arrse-about-face' for network configuration... Its also far more work if - no, when - the router is changed or the firmware updated) one has to recreate the entire reserved pool, ie re-enter by hand a list of MAC and IP addresses. OTOH, with a designed addressing strategy using manual addressing on the fixed clients, on simply has to change - at most - router's DHCP pool and it's address.
It's also one less area to have to check when there are issues, ie double checking the MAC addresses are correct, which has to be done by hand.
Can't see it being a firewall issue - why would internal LAN traffic be crossing the router firewall? Even if the laptop and synology boxes are connect via the router switch ports, they wouldn't be crossing the firewall as the rules are applied to the WAN port... unless the synology boxes are attached to the switch, in turn connected to a port on the router that has been designated a DMZ...
I too have an HP Microserver (NL54?), running OpenELEC, and a Synology NAS as well. Both are *nix based, but OpenELEC updates more often that Synology, presumably because the later is tested against a range of appliances, rather than the testing open source undergoes.
My Synology is running samba v4.1.20 build 7393 Jun 2 2016 (telnet/SSH to synology, type smbstatus --version)
Can't compare to the HP, as it's off at the moment (and have not tried accessing it via a PC).
OP = just a thought, see if this works. From a command box started as "run as administrator" type
net use <drive letter>: \\<servername>\<sharename> /persistent:yes
e.g. to map drive X: to Music on your diskstation
net use X: \\DISKSTATION\Music /persistent:yes
The music folder may need to uppercase (mine works either way).
There is another possibility that it's a master browser issue, but that's getting a little esoteric.
Ok what I would do is compare the setting off the lan adaptors making the wireless the same as the wired connection. Just go through them both and make sure the tick boxes etc are the same.
As a matter of interest is there any wireless lan software installed like the Intel Proset software for example?
I'm thinking of the Windows firewall (on the errant client) rather than the router firewall. As surmised, local LAN traffic doesn't transcend the router firewall so it's not relevant, but Windows clients have had a local "personal" firewall in the last few versions. There could be a scenario in a laptop with multiple NIC's, that the rulesets differ between the NIC's which could give rise to the observed behaviour (works one NIC and not the other.) Whilst I agree it's unlikey (SMB et al tends to be permitted by default) it would be fairly trivial to test and rule it out: Find the firewall control in Systems and Security, turn it off, test, then turn it back on again.
You might call it whatever you want that it is your opinion. Enterprise best practice does not extrapolate to small home LAN. MAC addresses are one of the easiest to get from the network configuration, the fact that they are in hexadecimal is neither here nor there. MAC addresses are a series of characters for most users. Most users in a home environment will have a very limited number of servers. One or two file, media servers a printer and pretty much everything else can have dynamic addresses.
Anybody who is doing it by hand will have to understand IP range, netmask and dns which can be very tricky for users who never have configured networks. A DCHP server will do all that without the user having to understand any network configuration. If the user understands networking very well then by all means go and configure it by hand. Otherwise allow the router to do all the work. It also guarantee that those device with more than one adapter will have the same IP.
I have a Synology NAS which has several services and network printer/fax/scanner and Windows, Linux, OSX systems as well as media devices like TV, players, amps, phones, etc, all working perfectly fine and none of them have ever lost access to one of my services, shares.
Static IP address configuration will always have the issue that if you networking configuration changes your static IP addresses might be out of range, wrong netmask or not direct access to the DNS servers specially if using DNS servers outside you LAN as you suggested.
I would tend to agree with @tich77 that it is not a firewall issue. If the windows 10 machine would be the one providing the service the firewall might be the one blame but the fact that it cannot find a service I would tend to find the problem in some sort of network configuration, user-password access to the service.
It's not opinion, it is established practice. The purpose of reserved IP addresses in DHCP is not opinion, it is fact. Like anything else, it can used for something else, in the same way a butter knife can be used as a screwdriver, but it's not recommended - the whole point of DHCP is to reduce client configuration, compared, for example, BOOTP (which is what reserved addressing stems from).
No, nothing extrapolates down <grin>. But enterprise LANs are no different to small (home, office) LANs writ large. And many of the strategies and techniques that have been developed to reduce the admin overhead in a large network can be applied just as well to a small one, where applicable, such as address allocation (see later)
I'd disagree that they are the 'easiest to get' because unless they are printed on the device, you have to know the relevant commands to extract them... and unlike an IP address, which is going to follow the same format for just about every thing on the same network (xxx.yyy.xxx.ABC) the user only has to remember ABC, not 8 pairs of mixed characters and numbers, which can be susceptible to transposition, difficult to remember, and not easy to enter unless you have the device in front of you. And that's before encountering different annotations used by different devices, which can bewilder those unfamiliar with the subject.
A local IP address is just a series of numbers, the first 9 of which are going to be same, or self-evidently need to be changed to be the same
No disagreement. But again, it's easier to make the changes to all static devices once, and once only (manually assign an address) and then only change once device (the DHCP server/router) going forwards. Its actually quicker to configure each such device to use a static address than to obtain the MAC address, tell it to use DHCP, then configure the DHCP server with the MAC address and reserved IP address for each device. Not to mention, what happens when you have to do it all over again because the DHCP server (router) has been replaced because one has changed the router....
There is nothing more to 'understand' than there is configuring a DHCP server with a reserved range, and a DHCP pool outside that range (and excluding the router address), and entering lots of 8 octect hexadecimal numbers and corresponding 12 digit IP addresses.
I'm not sure what you mean by the last sentence, as two devices cannot have the same IP, unless you are referring to link aggregation - which requires more knowledge on the user's part than manual IP addressing, especially if it goes wrong (either through initial configuration or later fault)
Glad to hear it, but it's not relevant
Not really. One just changes the router's IP address. For example, if I was using the network 192.168.1.0, router address .1.254, and my new router used the network 192.168.0.0 and an address of .0.1, all I need to do is change the router configuration to the previous 1.0 network and .1.254, and ditto the corresponding address range in the DHCP pool. No need to change any client at all.
Compare that to using reserved IP addresses, and changing the router. One still has to change the DHCP scope to exclude the reserved address range, and then add each reserved device's MAC address and IP address. A lot more work, no? And a greater risk of getting one of those hex numbers wrong - and troubleshooting why your device is not getting the IP address expected (or worse, if you use hardcoded IP shares, why 192.168.1.5 is NOT connecting to the Diskstation, for example!). Worse still, one has "lost" the list of devices and their MAC addresses, or didn't record the IP addresses, or both... a lot more work. Like I said, Reserved IP addressing in DHCP was for a very specific usage - diskless workstations that needed a constant IP address, as a hangover from BOOTP (which was hugely admin intensive as it was just a list of MAC addresses against IP addresses, maintained by hand).
Nothing is going to change the network mask, unless one decided to change the entire network address space, ie by subnetting the network.. at which point I don't think a user who has "never configured a network" and would find it "very tricky". And if one was going to do that, then an addressing strategy that has all static addresses at the top or bottom of the network range - again borrowed from the enterprise space - minimises the administration work in reconfiguration.
If it can access by IP address but not UNC name, then the firewall rules to check for are
135-139 UDP and TCP
445 UDP and TCP
if those port settings are allowed in the firewall (and they should be by default), bring up Control Panel, Administration Tools, Services. Look for a service called "Function Discovery Resource Publication" and change to Automatic
Sorry I am one for DHCP Reservation whether applied at an Enterprise or home level in preference to static addresses. The only real need for static's is the DHCP server or Primary AD etc.
It allows you to manage all your devices centrally and you know that you can centrally update DNS, gateways etc.
I also that disagree that's it difficult to obtain the MAC address, most routers these day (and DHCP servers) allow you to see what clients are connected and apply the reservation there and then. It's a simple mouse click.
Wow thats a lot to read. I will work through it tonight. Thanks all
Well, you can ignore the friendly debating re static vs reserved addressing, as it's of little relevance to the problem in hand; you don't appear to have an IP address conflict!
As you are using SMB (and hence UNC shares), can you try the steps in posts (in order of trying)
#45 - check the firewall if any)
135-139 UDP and TCP
445 UDP and TCP
#46 if those port settings are allowed in the firewall (and they should be by default), bring up Control Panel, Administration Tools, Services. Look for a service called "Function Discovery Resource Publication" and change to Automatic
#35 - 2. Windows 10 deletes and recreates network shares in the background, to conserve resources (!!!! Go figure). Open a cmd prompt as admin, and type
net config server /autodisconnect:-1
Out of interest are you credentials ok, i.e. the share on the NAS has the same user credentials and password as you are using on Windows ?
If you have different users on the Windows box it can cause issues though probably in this case but worth checking.
Mapping the shares as an admin user can potentially use different credentials too ...
I guess you have a lot to say but I repeat it is your opinion. Enterprises have a dedicated admin for it. Must home users do not have that luxury.
Regarding whatever is easier, let's agree to disagree. You have your opinion I have mine and they will never meet.
Stop banging about the hex number. It is not that difficult to copy and paste, needless to say that most people will not have a problem recognising digits from 0-9 and letters from a-f. Needless to say that most routers have a very intuitive interface and each device will have a different interface to configure the network.
Ok so done everything apart from the first point as can't find the info
It seems to now connect to the mapped drives via ip and via the server names. So looks like I'm heading in the right direction.
I can now also see my laptops shared folder under the network section of file explore but still not the servers.
It's only gone and started working!!! Not sure why showing as the ip address and not server names but hay it's working.
Thanks for everyone's help
If you use static ip address the router will have no knowledge of the name of the device. You could change that in the "hosts" file in your machine.
BOOTP is for diskless workstations not DHCP, although similar. BOOTP automatically reserves the same IP address. DHCP reservations are different.
By having static IP addresses on your network, if DNS is not updated then you won't be able to resolve the hostname to IP and will only be able to map to IP drives.
The IP address issue may well be as Har-One states due to you using static IPs that the router (normally provided DNS for DHCP Clients) does not know about.
If on the cmd prompt you do ping -a 192.168.0.103 it should come back and say the hostname. If not this is why its only displaying the IP address.
I tend to add a shortcut in Quick Access in explorer to any servers I might want. Then if explorer is not playing ball on the network option you can just access it that way.
Which is what I said (post #38). BOOTP doesn't strictly reserve the address, the BOOTP server has a configuration file that lists every MAC address which the corresponding address to serve to it, hence why BOOTP was such a PITA to administer; every time a NIC was changed (card, new PC, etc), the BOOTP file had to be updated. Been there, done that, on a 5000 seat network... and even when DHCP was introduced, still had to maintain BOOTP during a migration, and still had to use DHCP reserved addresses for special case workstations.. deep joy!
Agreed, in a wholly IP network, but not in a Windows-centric network as Windows maintains a list of device names via the network browser/discovery service. NBT takes care of it. However, some digging produces interesting results, which mean we are all right, and all wrong. Because: Microsoft.
I'm not running internal DNS (I forward to Google's), use static addresses for all infrastructure devices (switches, NAS, printers), ping -a 192.168.1.8 returns "Pinging DISKSTATION [192.168.1.8] with 32bytes of data... Windows will also maintain a list of learnt device names through the browser service.
A good fix, thanks MS!
Anyway, turns out that MS has made changes to Windows 10 networking 'under the bonnet', and not just between Windows x and Win10, but even between versions of Win 10. The result is that shares (shared drives/folders on non-MS devices) can sometimes from Win10. Its due to a change in NBT (NetBIOS over TCP), and the way Windows manages name resolution. Despite the WINS service supposedly being deprecated, its still in use, and can be a problem with some SOHO/home router's DHCP service: The default is for Windows to use NetBIOS from the DHCP server. This is fine, provided the DHCP server learns NBT names and can serve them back as NBT names* If it doesn't, or it does not learn/supply names, then Windows 'forgets' the shares. I'm looking for a reg setting that controls the time before names age out (similar to ARP cache aging), which will also help alleviate the problem.
Control Panel | Network and Sharing Centre. Click on the affected network interface (usually ethernet for desktops or wireless for laptops) Click on Ethernet Properties. Click Protocol Version 4 (TCP/IP v4). Click Properties. Click Advanced button. Click on the WINS tab.
If the setting is "Default: Use NetBIOS from the DHCP server...", click on the "Enable NetBIOS over TCP/IP" button, then OK, and ok/save out from the control boxes.
We are we all right? Well, because if you use Reserved DHCP addresses (Har-One and ChuckMountain), provided the router can be configured with the device name (or it just learns it), then the problem does not occur (or shouldn't!).
All wrong? Because this is not what reserved addressing was designed for, and if the router (or rather, it's DHCP implementation) doesn't support name assignation for rDHCP, it doesn't work either....
*This is my stab at explaining it in simple terms, from a conversation last night over some wireshark captures. The Technicolour router does support names in reserved DHCP, but will not learn them from the network. A Cisco does [/i]not support[/i] names in rDHCP, just mac address and IP (its an old IOS though). Interestingly, wireless traffic exhibited different behavior to wired, but this could be due to other reasons.
That made me smile - how many years have MS been asserting that position - about 16-17 isn't it...? But it seems they've still not yet completely let it go.
its still 50/50, somtimes it conects to the mapped drives via \\micro2,always ok via ip. but 50/50 at showing under network
I will recommend to reserve the IP using the facility within the router and all those problems will be gone for all machines accessing the server.
Alternative, you could use the hosts file. However, this solution has to be implemented for all machines accessing the server. The machine will look at this file before querying the DNS server.
In Win10 in this directory "C:\Windows\System32\Drivers\etc" There is file called hosts if that file does not exist there is one called lmhosts.sam copy this file to hosts. Note that you will need admin rights for this.
ie. cp lmhosts.sam hosts
Then open hosts file with notepad or any text editor you are familiar with and add this line.
XXX.XXX.XXX.XXX full.domain.name alias
XXX.XXX.XXX.XXX is the IP of your server.
full.domain.name is the full name of the server if any eg. micro2.home.net
alias is the short name for it eg: micro2
more or less it will look like this
192.168.0.103 micro2.home.net micro2
After doing that you will always find the server as long as its IP does not change.
Separate names with a comma.