May 16, 201016 yr Im being an idiot and im sure i worked out the answer before but when i try: smbmount //tower2/ /mnt/tower2 its connecting but always asks for a password. Have i inadvertently added a password somewhere cause no GUI browsers on linux or windows needs one.?
May 16, 201016 yr Im being an idiot and im sure i worked out the answer before but when i try: smbmount //tower2/ /mnt/tower2 its connecting but always asks for a password. Have i inadvertently added a password somewhere cause no GUI browsers on linux or windows needs one.? The above won't work. You mount shares, not servers. "//tower2/" is a server. What would work is: smbmount //tower2/disk1 /mnt/tower2/disk1 If you don't want it to prompt you for the blank password, do this: smbmount //tower2/disk1 /mnt/tower2/disk1 -o pass=
May 17, 201016 yr Author Yeah sorry i used to short an example. Same results using disk1 etc The problem is a blank password will not work.
May 18, 201016 yr Author your post sparked a thought. seems it works with the ip and not with the box name what had me perplexed is that it asked for a password. so i check the ip that pinging the hostname gives 67.215.65.132 so this is opendns silly default when it cant find one. curious
May 18, 201016 yr your post sparked a thought. seems it works with the ip and not with the box name what had me perplexed is that it asked for a password. so i check the ip that pinging the hostname gives 67.215.65.132 so this is opendns silly default when it cant find one. curious This sparks another thought on my side...this is what i observed from my stock unRAID in a VM: The hostname (not FQDN) is propagated into /etc/hosts but for the loopback interface. For eth0 (on DHCP) the hostname and FQDN is propagated back to DNS (and not into /etc/hosts) So a ping to "tower" locally in an unraid shell will resolve to loopback not the real net interface. -> every external client can resolve fine, but a local app could end up in resolving the IP wrong (incoming through an external trigger though, but what if resolve-calls are internally nested somehow?). Giving the IP instead of hostname would make this behaviour disappear. So...is it a bug or feature? unRAID without a real net makes no sense. Giving the hostname to loopback in /etc/hosts is considered as bad manners in some parts of the world I'd vote for a bug
May 25, 201016 yr I once had this behavior when I put my external hostname as the search parameter in /etc/resolv.conf What happens is that once the dns lookup can't find the host, it adds that part to it and searches again. That way if my host would be client123.myisp.net it would come up with tower.client123.myisp.net. That way, if a domain couldn't be resolved, it would always come up with my external ip. Very nasty indeed.
May 25, 201016 yr I once had this behavior when I put my external hostname as the search parameter in /etc/resolv.conf What happens is that once the dns lookup can't find the host, it adds that part to it and searches again. That way if my host would be client123.myisp.net it would come up with tower.client123.myisp.net. That way, if a domain couldn't be resolved, it would always come up with my external ip. Very nasty indeed. ...but what you used is a feature. Putting a hostname into parts of the system that would only allow domain-names is just satisfying a system the wrong way. So the behaviour you describe is only to be expectd Put hostnames, which should resolve locally into /etc/hosts and you are fine...
May 25, 201016 yr Author I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other.
May 25, 201016 yr I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other. Hmm...I am not sure if I understand that right... I would agree on the feature of "knowing each other" in terms of name resolution for easy connectivity as reasonable. In terms of "configuration", which I would understand as a feature to provision each unRaid install locally with the right config, I would think that this is unreasonable. The first can be achieved by setting up your network DNS and IP provisioning and would not require to change the config of a single unRAID instance if changes occur (when using DHCP). The second would call for central maintenance, deployment and provisioning infrastructure (what happens in a scenario where TOWER3 should be added later...this will result in a need for change of TOWER1 and TOWER2, wouldn't it?)
May 25, 201016 yr ...but what you used is a feature. Putting a hostname into parts of the system that would only allow domain-names is just satisfying a system the wrong way. So the behaviour you describe is only to be expectd Put hostnames, which should resolve locally into /etc/hosts and you are fine... Hey, I was young and put the wrong vars in the wrong places . I misread and didn't know that said IP belongs to opendns, my bad.
May 25, 201016 yr Author I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other. Hmm...I am not sure if I understand that right... I would agree on the feature of "knowing each other" in terms of name resolution for easy connectivity as reasonable. In terms of "configuration", which I would understand as a feature to provision each unRaid install locally with the right config, I would think that this is unreasonable. The first can be achieved by setting up your network DNS and IP provisioning and would not require to change the config of a single unRAID instance if changes occur (when using DHCP). The second would call for central maintenance, deployment and provisioning infrastructure (what happens in a scenario where TOWER3 should be added later...this will result in a need for change of TOWER1 and TOWER2, wouldn't it?) I perhaps kept it to simple. Let me put it another way. If I plug a random windows box into my LAN and ping TOWER1 then the correct IP replys. If i plug a new unRAID into my LAN and ping TOWER1 then an incorrect IP replys. Keeping away from the technical reasoning for this at the moment this is what i was referring to as "I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other."
May 27, 201016 yr I perhaps kept it to simple. Let me put it another way. If I plug a random windows box into my LAN and ping TOWER1 then the correct IP replys. If i plug a new unRAID into my LAN and ping TOWER1 then an incorrect IP replys. Keeping away from the technical reasoning for this at the moment this is what i was referring to as "I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other." Ha!...OK, that's a usecase and feature I can understand
Archived
This topic is now archived and is closed to further replies.