From Bugzilla Helper: User-Agent: Mozilla/5.0 Description of problem: I tried to mount the share via the command line. I did this: smbmount //EUGENIA/ShareDir /home/eugenia/samba -o username=Eugenia1 password=XXX ip=10.0.0.10 The error I was getting was that there is no route to host for 10.0.0.19. However, my PC is 10.0.0.10 and I even specifically ask for this IP via the ip attribute in the command line (but it seems the app defaults to the requested PC name first). I got to XP's control panel and checked around if my PC broadcasts more than 1 IP address, and I was right. I have a VMWare virtual ethernet device there, which has a 10.0.0.19 address! Older Samba version other distros use is able to see the right IP address from the real ethernet device, and not the "virtual" device VMWare is exposing for its needed NAT abilities. I checked all my settings on my XP PRO and they all seem fine. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: smbmount //EUGENIA/ShareDir /home/eugenia/samba -o username=Eugenia1 password=XXX ip=10.0.0.10 Actual Results: Error that there is no route to host 10.0.0.19 Expected Results: To be able to mount the right share from the right IP address on /home/eugenia/samba Additional info:
Shouldn't you use -o param=value , param=value instead of -o param=value param=value ? I think that without "," only the 1st is processed.
I tried that too, no good. The problem here is that smbmount is trying to connect to 10.0.0.19 and not to the .10. However, this morning I tried to mount the share by IP address (smbmount //10.0.0.10/ShareDir etc) and by doing so this way, it gave me two error messages, but it did managed to mount the share successfully. But doing so the normal way, by machine name, it won't do it because it gets confused by the two IPs.
It sounds like you have a generic problem in hostname lookup. What does getent hosts eugenia display?
It displays nothing... getent gets its values from some "databases" and my WinXP machine is not registered in these dbs under the linux installation. It doesn't have to anyway, it should just look up the network for the requested value if it can't find it in the dbs.
New info: I installed Fedora Core, and the bug is _still_ there. I speak of a bug and not of something else, because Slackware 9.1 on the _same machine_ sees these samba shares just fine! I did not configure _anything_, nautilus on Slackware just works with my windows shares. On the brand new Fedora instllation and RHL9, it just doesn't work!
[This is a mass update sent to many bugs that missed earlier such messages due to having their version set to a test version.] This bug was originally filed against a version of Fedora Core which is no longer supported, even for security updates. Many changes have occured since then. Please retest this bug against a still supported version. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. If it still occurs on FC5 or FC6, please assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier. This bug will be closed after a few weeks if no information is given indicating that the bug is still present in a supported release.
Closing per lack of response to previous request for information. This bug was originally filed against a much earlier version of Fedora Core, and significant changes have taken place since the last version for which this bug is confirmed. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier.