Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 Description of problem: Trying to connect via Nautilus on my WinXP PRO shared directory (N:\ShareDir\ local name, //EUGENIA/ShareDir via samba). I entered in the URL bar: smb://10.0.0.10 and it would either not connect at all, or it will prompt me for login/password, and after I will give it the pass it will either tell me that I don't have the necessary permissions, or it will show the actual files. IF it will show me the files in that dir, when I try to do anything with them, again, it will tell me that either don't have permissions, or that it will again ask me for login/pass. This "random" behavior happens all the time, I can't get a connection where I can copy/paste a file or do some work. If I am lucky, I will just get a file list, but the luck stops there. (please note, SuSE, Lindows and MacOSX can work fine with that share). The settings on the XP machine for this directory on its Properties/Sharing panel are like this: "Network Sharing and Security" Share this folder on the network (checked) Allow network users to change my files (checked) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Open Nautilus and browse to smb://10.0.0.10 2. Login/pass dialog comes up, fill it up. 3. Several things happen after that, in random. Actual Results: Either I won't have permissions, or it will give me a file list where I can't do anything with it (I can see the files, but can't do anything with them), or it will ask me again for a login/pass after I try to navigate into another folder in that share etc. Expected Results: Browse the share normally and be able to copy/paste/move/delete files. Additional info: smb.conf has default values. However, I added a user into it via smbadduser, but I still get the same results. Also, the XP machine exposes two IP addresses, one is 10.0.0.10 via its 3Com ethernet card and the other one is 10.0.0.19 via the virtual device of VMWare (VMWare uses that as a NAT device in order the emulated OSes to be able to use my home network and access the internet).
Please note that Konqueror has a similar behavior.
Do you still get this in gnome 2.8 from fc3?
I don't have FC3 and I won't install the test version just for these tests (4 CDs???). This report already shows how to reproduce this bug. The problem is VMWare and the fact that XP exposes two IP addresses (one via its ethernet card and one via VMWare's virtual ethernet device). Samba gets confused because of it (at least it was). I tries to connect to the VMWare address instead of the real address. That's the bug. I filed this bug almost 2 years ago. If you hadn't the time to reproduce this bug by installing XP and the demo of VMWare, then I can only say this: 1. You don't really care about this bug, so I don't care either about Fedora. 2. Your testing procedures over at Red Hat are amateurish and you don't test everything like Microsoft does, resulting to lower software quality. 3. You are wasting your time by asking me to do the work for you. FC3- test is 4 CDs (see: freaking bloated), it's a waste of my time and if I can judge of the work that has been done on this bug for 2 years now (see: none), it's probably a waste of your time too. FYI, I had to remove VMWare off my XP system just so I can be compatible with Nautilus. I did this last year, and then Nautilus worked fine. But this is something I shouldn't have to do. The bug should have been fixed by now, closed as "won't fix" or it should have been reported upstream to the Samba people. Leaving it open like that it won't fix itself. I am disssapointed.
>I tries to connect to the VMWare address instead of the real address. EVEN when you specifically ask smbmount or nautilus to mount the right IP address (10.0.0.10). It keeps trying to mount the vmware IP address 10.0.0.19 for some reason (vmware, which doesn't even run at that point). That's the bug in a nutshell. Mac OS X and other distros didn't exhibit the bug.
konq/nautilus/smbmount all affected, reassigning.
Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc. They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/) for security updates only. If this is a security issue, please reassign to the 'Fedora Legacy' product in bugzilla. Please note that Legacy security update support for these products will stop on December 31st, 2006. If this is not a security issue, please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. If you are currently still running Red Hat Linux 7.3 or 9, please note that Fedora Legacy security update support for these products will stop on December 31st, 2006. You are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a security issue, please change the product as necessary. We thank you for your help, and apologize again that we haven't handled these issues to this point.
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc. f you are currently still running Red Hat Linux 7.3 or 9, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Closing as CANTFIX.