Bug 5417 - Mounting Windows2003 shares in fstab makes them unusable (RHEL5.1_64)
Mounting Windows2003 shares in fstab makes them unusable (RHEL5.1_64)
Status: RESOLVED WORKSFORME
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
x64 Linux
: P3 major
: ---
Assigned To: Jeff Layton
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-25 11:37 UTC by Jeffrey G Thomas
Modified: 2009-06-22 07:35 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey G Thomas 2008-04-25 11:37:40 UTC
Red Hat Enterprise Linux 5.1 - 64bit

I am having some strange Samba/CIFS mounting issues.  I am trying to mount some Windows 2003 Server r2 file shares, and although I can mount them and 'ls' them, i cannot do anything with them.  The files are being seen as directories, I can CD to the files, and I can even CD to non-existant directories.  Can anyone look at the following info and help me out?

modinfo cifs |grep version
version:        1.48aRH
srcversion:     A7F70DFEAE2BF6EBBDE18A1

[shell]
[root@plus mnt]# ls -la /mnt/data/ 
total 34642
drwxrwxrwx 1 root root       0 Apr 24 08:34 .
drwxr-xr-x 5 root root    4096 Apr 21 15:17 ..
-rwxrwxrwx 1 root root  132508 Feb 21  2007 0220EM.CSV
-rwxrwxrwx 1 root root  147776 Jun 13  2007 061307.CSV
-rwxrwxrwx 1 root root  232448 Jun 13  2007 061307.xls

[root@plus mnt]# file data/0220EM.CSV
data/0220EM.CSV: directory
[/shell]

0220EM.CSV is NOT a directory but a file.  Additionally, if I CD to that directory and 'ls' there it gives me the same output as the /mnt/data/ directory does, meaning its recursing upon itself or something.

Additionally I can 'cd /mnt/data/fakedir/' and (1) it actually goes there, and (2) 'ls' gives the same output as 'ls /mnt/data/' :

[shell]
[root@plus mnt]# cd data/fakedir
[root@plus fakedir]# ls -la
total 34634
drwxrwxrwx 1 root root       0 Apr 24 08:34 .
drwxrwxrwx 1 root root       0 Apr 24 08:34 ..
-rwxrwxrwx 1 root root  132508 Feb 21  2007 0220EM.CSV
-rwxrwxrwx 1 root root  147776 Jun 13  2007 061307.CSV
-rwxrwxrwx 1 root root  232448 Jun 13  2007 061307.xls
-rwxrwxrwx 1 root root   27990 Apr 21 13:55 0804GB.txt
[/shell]

This is my current /etc/fstab:

[shell]
[root@plus ~]# cat /etc/fstab
LABEL=/                 /                       ext3    defaults        1 1
LABEL=/var              /var                    ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sda3         swap                    swap    defaults        0 0

\\exchange\import  /mnt/import  cifs  credentials=/root/.cred,gid=500,uid=500,file_mode=0777,dir_mode=0777  0  0
\\exchange\mmnew  /mnt/mmnew  cifs  credentials=/root/.cred,user,gid=500,uid=500,file_mode=0777,dir_mode=0777  0  0
\\exchange\brokerline  /usr/MAIL.ATTACH  cifs  credentials=/root/.cred,gid=500,uid=500,file_mode=0777,dir_mode=0777  0  0
\\exchange\data  /mnt/data  cifs  credentials=/root/.cred,gid=500,user,uid=500,file_mode=0777,dir_mode=0777  0  0

## 'smbfs' gives the error, "mount: unknown filesystem type 'smbfs' "
##//exchange/data  /mnt/data  smbfs  credentials=/root/.cred,gid=500,user,uid=500,file_mode=0777,dir_mode=0777  0  0



[root@plus ~]# file /mnt/data/0220EM.CSV
/mnt/data/0220EM.CSV: directory

[root@plus ~]# cd /mnt/data/0220EM.CSV

[root@plus 0220EM.CSV]# ls
0220EM.CSV
061307.CSV
061307.xls
....
....
[/shell]
Comment 1 Jeffrey G Thomas 2008-04-28 16:43:32 UTC
Same issue here, different distro:
http://ubuntuforums.org/showthread.php?p=3026260
Comment 2 Jeff Layton 2008-09-24 08:25:05 UTC
Is this still an issue on RHEL with a more updated kernel and samba-client package? I suspect that the problem may have been with how delimiters were being treated in CIFS at one point...
Comment 3 Jeff Layton 2009-06-22 07:35:19 UTC
No response in a very long time. Please reopen if this is still a problem.