Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160750 - after FC3->FC4 upgrade, cifs mounts are hanging
Summary: after FC3->FC4 upgrade, cifs mounts are hanging
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-17 02:39 UTC by Adil Hindistan
Modified: 2015-01-04 22:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-05-04 13:54:10 UTC

Attachments (Terms of Use)

Description Adil Hindistan 2005-06-17 02:39:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
I had  mount points that connected to different XP shares using something like
mount -t cifs -o username={username},password={password] //{machine_name}/{share} /mnt/c

There does not seem to be a problem during mounting (either by mount -a or after reboot) but then when I try to access the mount point, what used to be an instant thing takes ages now and I get no response back.
If I replace cifs mount with smbfs, everything is back to up to normal speed and I can immediately cd /mnt/c.  

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

How reproducible:

Steps to Reproduce:
1. create a mount point mkdir /mnt/c 
2. Mount the share mount -t cifs -o username={username},password={password] //{machine_name}/c$ /mnt/c

put this into /etc/fstab//ahxp/c$  /mnt/c cifs    user,password 0 0
3. mount -a or reboot
4. ls -l /mnt hangs... you can not cd /mnt/c; it hangs

Actual Results:  system hangs...I did this in terminal screen and waited for hours, it never come back

Expected Results:  should be able to access 

Additional info:

I rebooted my linux box and retried it. Nothing has changed.  However, I have just run yum upgrade today and I don't know if anything has changed back I am now able to access cifs mounted mount points.

Last updates:
 Package                 Arch       Version          Repository        Size
 NetworkManager          i386       0.4-18.FC4       updates-released  181 k
 NetworkManager-gnome    i386       0.4-18.FC4       updates-released   96 k
 parted                  i386       1.6.22-3.FC4     updates-released  524 k
 spamassassin            i386       3.0.4-1.fc4      updates-released  685 k
 system-config-securitylevel  i386        updates-released  376 k
 system-config-securitylevel-tui  i386        updates-released 361 k

Transaction Summary

Comment 1 Adil Hindistan 2005-06-19 01:00:21 UTC
This is a good example of how much time it takes:  
[root@ahlnx ~] cd /mnt
[root@ahlnx /mnt] time ls -l
total 9
drwxr-xr-x   4 root root 1024 May 31 18:30 bootMandriva
drwxrwxrwx   1 root root    0 Jun 17 00:18 c
drwxrwxrwx   1 root root    0 Jun 17 00:18 f
drwxrwxrwx   1 root root    0 Jun 17 00:18 m
drwxr-xr-x  18 root adm  4096 May 31 18:53 Mandriva
drwxr-xr-x   1 root root 4096 Jun 15 23:08 sambam

real    15m25.559s
user    0m0.000s
sys     0m0.012s

After waiting for 15mins, now I can cd to it.  This is not happening if I use
smbfs and it was NOT happening at FC3
[root@ahlnx /mnt] cd c
[root@ahlnx /mnt/c] time ls -l
total 303
-rwxrwSrwt  1 root root   2052 Jul 14  2004 A2Debug.txt
-rwxrwSrwt  1 root root      0 Dec 12  2003 AUTOEXEC.BAT
-r-xr-Sr-t  1 root root    211 Jun 12 19:45 boot.ini
drwxrwxrwx  1 root root      0 Jul 14  2004 Compaq
-rwxrwSrwt  1 root root      0 Dec 12  2003 CONFIG.SYS
-r-xr-Sr-t  1 root root      0 Dec 12  2003 IO.SYS
-rwxrwSrwt  1 root root     90 Aug 12  2004 LogiSetup.log
-r-xr-Sr-t  1 root root      0 Dec 12  2003 MSDOS.SYS
-r-xr-Sr-t  1 root root  47564 Aug 11  2004 NTDETECT.COM
-r-xr-Sr-t  1 root root 250032 Aug 11  2004 ntldr
drwxrwxrwx  1 root root      0 Aug  4  2004 Program Files
drwxrwxrwx  1 root root      0 Dec 12  2003 RECYCLER
-rwxrwSrwt  1 root root    432 May 31 22:48 sound.txt
drwxrwxrwx  1 root root      0 Aug 11  2004 System Volume Information
drwxrwxrwx  1 root root      0 Jun 18 20:44 Temp
-rwxrwSrwt  1 root root    140 May 18 22:12 YServer.txt

real    0m0.008s
user    0m0.002s
sys     0m0.003s

Comment 2 Adil Hindistan 2005-06-19 01:02:39 UTC
OH, BTW, here is the mount information
[root@ahlnx /mnt/c] mount -l
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda3 on /boot type ext3 (rw) [/boot]
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
//ahxp/f$ on /mnt/f type cifs (rw,mand,noexec,nosuid,nodev)
//ahxp/m$ on /mnt/m type cifs (rw,mand,noexec,nosuid,nodev)
//ahxp/c$ on /mnt/c type cifs (rw,mand,noexec,nosuid,nodev)
automount(pid2243) on /net type autofs (rw,fd=4,pgrp=2243,minproto=2,maxproto=4)
automount(pid2233) on /misc type autofs (rw,fd=4,pgrp=2233,minproto=2,maxproto=4)
/dev/sda1 on /mnt/bootMandriva type ext3 (rw,noexec,nosuid,nodev,user=adil)
/dev/sda6 on /mnt/Mandriva type ext3 (rw,noexec,nosuid,nodev,user=adil)
//ahxp/m$ on /mnt/sambam type smbfs (0)

...and /etc/fstab:[root@ahlnx /mnt/c] cat /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
/dev/sda5               swap                    swap    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
/dev/sda6               /mnt/Mandriva           ext3    user,noauto  0 0
/dev/sda1               /mnt/bootMandriva       ext3    user,noauto 0 0
# below 3 lines use samba to access windows shares
#//ahxp/f$              /mnt/f                  smbfs  
user,credentials=/etc/cred 0 0
#//ahxp/m$              /mnt/m                  smbfs  
user,credentials=/etc/cred 0 0
#//ahxp/c$              /mnt/c                  smbfs  
user,credentials=/etc/cred 0 0
# below 3 lines use cifs which seems to be faster than samba
//ahxp/f$               /mnt/f                  cifs   
user,credentials=/etc/cred 0 0
//ahxp/m$               /mnt/m                  cifs   
user,credentials=/etc/cred 0 0
//ahxp/c$               /mnt/c                  cifs   
user,credentials=/etc/cred 0 0

/dev/fd0                /media/floppy           auto   
pamconsole,exec,noauto,managed 0 0
/dev/hdc                /media/cdrom            auto   
pamconsole,exec,noauto,managed 0 0

Comment 3 Dave Jones 2005-07-15 21:11:02 UTC
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak

Thank you.

Comment 4 Adil Hindistan 2005-07-18 03:49:42 UTC

There is no change in the problem.  As a matter of fact, I did have kernel-panic
issue and as a result, I rebuilt my system from scratch using FC4 DVD.  I still
have problems with cifs or smbfs mounting.  They keep on hanging when I try to
access them.  A simple ls -l /mnt/c would take about 15 minutes and then I am
able to access all mounted windows shares normally.  If I do not touch my pc for
a long time ( say 5-6 hours) and come back, again it takes about 15-20 mins the
first time to access these mount points.

Comment 5 Trevor Cordes 2005-08-05 18:01:02 UTC
Idea: how many machines are on your network?  Are the XP boxes Home or Pro?  Try
turning off every machine except the linux and one XP box with a share.  Reboot
the XP box.  Then try it.  If you have printer or file shares on an XP box and
you have 3-5+ XP machines they can eat up all the 5 (Home) or 10 (Pro)
connections XP allows and then XP starts hanging/denying connections in strange

Also, try putting the -o options after the share/mount spec.

Comment 6 Adil Hindistan 2005-08-09 02:29:01 UTC
I have 2 XP Pro machines but I am connecting to one of them only. I have no
'shares' except the default XP administrative shares (ie.c$, d$ etc) which I
connect to.  I did use -o option (please see the description I have on top of
this page).  

Interesting enough, recently I noticed that I had no delays accessing to mount
points and I was thinking that it was probably one of the kernel updates that
resolved the issue but that did not live long and I started to experience the
same delays.

I keep on testing different configurations.  Last I tried was to mount one of
the drives with smbfs, the other 2 with cifs.  Interestingly, I was able to
access to smbfs immediately after a reboot but cifs mount points points were
taking 15 mins to connect.

As I have not changed anything on my XP boxes for the last couple of months and
I never had such issues until I started using FC4, I tend to think this is on
linux side.    


Comment 7 Dave Jones 2005-09-30 06:17:27 UTC
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel ( As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.


Comment 8 Dave Jones 2005-11-10 19:15:42 UTC
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.

Comment 9 Dave Jones 2006-02-03 06:37:16 UTC
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.

Comment 10 John Thacker 2006-05-04 13:54:10 UTC
Closing per previous comment.

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