Bug 118168 - Some Windows 2000 shares will not mount with mount.cifs
Some Windows 2000 shares will not mount with mount.cifs
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-12 14:12 EST by W. Michael Petullo
Modified: 2015-01-04 17:04 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.6.10-1.1134_FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-11 16:18:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description W. Michael Petullo 2004-03-12 14:12:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040217 Epiphany/1.1.10

Description of problem:
I am having trouble mounting some volumes off a Windows 2000 server. 
The volumes worked fine using smbmount from Fedora Core 1 but now fail
when using Fedora Rawhide.

Version-Release number of selected component (if applicable):
samba-client-3.0.2a-1

How reproducible:
Always

Steps to Reproduce:
Here is what I was doing with smbmount:

smbmount //chifs1-2k/Game_Design /mnt/gd -o
username=XXX,password=XXX,workgroup=XXX

This worked fine, though the permissions a a little odd because the
shared point of the volume I want
(Game_Design/Game_Materials_In_Design) is actually inside Game_Design
(see additional information below):

"ls /mnt/gd" says "permission denied" but "ls
/mnt/gd/Game_Materials_In_Design" works fine.

However, the mount.cifs command will not cooperate.  "mount.cifs
//chifs1-2k/Game_Design /mnt/gs -o username=XXX,password=XXX" says:

mount error 20 = Not a directory
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

and "mount.cifs //chifs1-2k/Game_Design/Game_Materials_In_Development
/mnt/gs -o username=XXX,password=XXX" says:

mount error 6 = No such device or address
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Other volumes mount fine with mount.cifs.  For example //chifs1-2k/Art
mounts fine (see additional information below).

Additional info:

I'm not sure if this problem is due to Samba or the kernel's cifs module.

When I asked the Windows administrators around here what might be
wrong, they said:

> The problem you are having accessing shares in Linux probably has 
> to do with the way the directories are shared. The Art directory
> gives Everyone permission to view Folder Content so \\Chifs1-2k\Art 
> is the actual share point. The Game_Design directory is not an 
> actual share point - all of the permissions are assigned at the next 
> level down - for example - 
> \\Chifs1-2k\Game_Design\Game_Materials_In_Development
Comment 1 W. Michael Petullo 2004-03-12 14:37:59 EST
For what it is worth, viewing the location "smb://chifs1-
2k/Game_Design/Game_Materials_In_Development" using nautilus 2.5.8-1 
works fine (after I enter my username and password).
Comment 2 W. Michael Petullo 2004-03-29 20:35:53 EST
This problem still exists in samba-common-3.0.2a-1.1 (Fedora Core 2
Test 2).
Comment 3 Jay Fenlason 2004-04-07 12:14:35 EDT
This is a bug in the smbfs Linux kernel module,and has nothing to do
with Samba per se.  I'm reassigning this to the kernel maintainers.
Comment 4 W. Michael Petullo 2004-04-07 12:37:55 EDT
I think this is a bug in the cifs kernel module, not smbfs.  Its only 
when I use cifs that I really have problems (see opening comment).
Comment 5 Dave Jones 2004-12-08 00:45:47 EST
any better with the 2.6.9 update kernel ?
Comment 6 W. Michael Petullo 2004-12-08 12:52:48 EST
The situation is the same as that stated in the original post and
comment #1.  I am now using kernel-2.6.9-1.1020_FC4 and
samba-client-3.0.9-2.
Comment 7 W. Michael Petullo 2005-02-11 16:18:01 EST
This seems fixed as of 2.6.10-1.1134_FC4.  "mount.cifs
//chifs1-2k/Game_Design/Game_Materials_In_Development
/mnt -o username=XXX,password=XXX" works fine now.  Either the kernel is fixed
or our system administrators changed something.

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