Bug 147699 - Mounted directories from Windows hangs for non root users
Mounted directories from Windows hangs for non root users
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Simo Sorce
Depends On:
  Show dependency treegraph
Reported: 2005-02-10 12:50 EST by Alexander Adam
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-14 11:51:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Samba log with socket errors (1.26 KB, text/plain)
2005-02-15 10:08 EST, Alexander Adam
no flags Details

  None (edit)
Description Alexander Adam 2005-02-10 12:50:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
I'm using Fedora Core 3 under VMWARE Workstation 4.5.2.
(I have also a Red Hat 9 installation running under VMWare).

When I mount my users homedirectory from Windows (XP),
with username=xaa, then I have constant 'hangs' for about
30-60 seconds until I see the contents of the directory,
selected with the Explorer. The same 'hangs' appear, when I try to
access the mounted drive from a Windows/DOS Command Prompt.

e.g. net use x: \\fedora3\xaa
when I enter x:
or on x: cd tmp

I have no problems, when I mount the directory with the root user,
or when I mount a samba directory, which can be used by root only.

I have no firewall activated, and I've tried the same with
SELinux disabled. But disabling SELinux has no effect. 
The hangs are the same.

It also make no difference if I share [homes], or if I define a
seperate entry to smb.conf (e.g.) [xaa$] which points to /home/xaa.
If I mount the share as root everything is fine. 
If I mount it as xaa, I have the hangs.
But after the hangs, I see the correct directory entries.

Maybe it is connected to bug/item: 141008

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Mount users home-directory from windows (e.g. \\fedora3\xaa)
2.Select mounted drive
3.change/select a subdirectory

Actual Results:  System hangs/needs a long time to show content of
selected directory

Expected Results:  Entries should appear immediately

Additional info:
Comment 1 Jay Fenlason 2005-02-14 15:14:51 EST
Can the Fedora box do a successfull DNS lookup of the Windows 
machine's IP address?  It may be timing out waiting for DNS, which 
can confuse your timing tests by caching the lack of replies. 
Does adding "smb ports = 139" or "smb ports = 445" to the [global] 
section of your smb.conf file make any difference?  (Don't add both 
at the same time, of course.) 
It might also be interesting to run ethereal on the Fedora box and 
see what's happening on the network. 
Comment 2 Alexander Adam 2005-02-15 10:08:12 EST
Created attachment 111089 [details]
Samba log with socket errors
Comment 3 Alexander Adam 2005-02-15 10:11:38 EST
nslookup returns, but cannot give the Windows machine's IP address.
The address is defined in my /etc/hosts. So ping works fine.

Adding smb ports = 139 or 445 does not change anything.
Comment 4 Jay Fenlason 2005-02-15 11:05:06 EST
Sounds like you need to fix your name resolution problem, and then 
Samba will be happy.  What does /etc/nsswitch.conf say for hosts:? 
Comment 5 Alexander Adam 2005-02-16 03:37:23 EST
I hope you are right. 
I have never used my own DNS or NIS server,
and I have to confess that I never really understand the background
and why the command
host fedora3 
Host fedora3 not found: 3(NXDOMAIN) and
nslookup fedora3

** server can't find fedora3: NXDOMAIN
ping fedora3
PING fedora3 ( 56(84) bytes of data.
64 bytes from fedora3 ( icmp_seq=0 ttl=64 time=0.112 ms

and works, and so does the rest of my network and internet.

But to your question:
in /etc/nsswitch.conf then entry for hosts is:
hosts:      files dns
Comment 6 Alexander Adam 2005-02-16 03:44:55 EST
My network and samba definitions under my RedHat9 VMWare session 
are similar (I use another IP address, but the rest is the same).
There also ping works, but host and nslookup does not.
But samba works fine, and I run all on the same PC/Windows-VMWare.
I also wonder, why does the root user do not have this samba problems ?
Comment 7 Alexander Adam 2005-02-18 03:33:02 EST
I've made some more tests:
I've added /opt/xml4c as [xml4c$] to my smb.conf file.
If valid users = root xaa, I get the same hanging effect.
No matter if I'm using root or xaa to use the share.
But if I only have valid users = root, I see no problems.
I can add files to the directory, browse the docs with
InternetExplorer, etc.
If I use another user than xaa I have the same hanging problems.
My samba only seems to work if root is the only valid user.
Comment 8 Alexander Adam 2005-03-09 04:22:34 EST
I've found a new fact for my problem - and a way to avoid my hangs.
- On my Windows PC where the VMWare Image of fedora3 (and of RedHat9)
  runs - I had re-defined my DVD-ROM Drive from D: to Y:.
  I often use Y: for CD-ROMs or DVD-ROMs, so I always know what Drive-
  letter is used - independent from the number of harddrives.
Since my user is xaa I've used drive X: to mount my /home/xaa via samba.
And it seems that I've always used drive Z: (which is the first
suggested by WinXP) to mount any directory with the root user.
I've always thought that root works and xaa did not, but in fact Z:
works and X: did not - no matter what user I'm using.
X: comes before Y: (DVD-ROM) and Z: comes after.
So I've tried to set back my DVD-ROM to Drive letter D:
And now samba works fine with fedora3 for all Users and all Drive
letters > D:
Don't ask me what's going wrong here - and why my RedHat9 Virtual
Machine under VMWare does not have those problems with samba and the
DVD-ROM on Y:.
But maybe that's a hint for you.
Comment 9 Matthew Miller 2006-07-10 17:04:15 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Note You need to log in before you can comment on or make changes to this bug.