1

gentoo, kernel 3.7.10
samba 3.6.12
SMB/CIFS server: Windows Server 2003 3790 Service Pack 2

I've encountered the situation when mount.cifs behaves differently from smbclient program.

The following command works fine. I can log in the server and navigate through the share's contents.

smbclient -U domainname/username //server.name/sharename

And if I try to mount this very share folder with the following command,

mount -t cifs //server.name/sharename /mount/point -o user=domainname/username

then the command itself works fine (return code is 0, no error message). But /mount/point looks empty.

What's the problem? Why mound.cifs and smbclient behave differently? Maybe smbclient uses some hidden settings?

BTW, I don't know whether it is relevant to the problem but anyway. If I run mount.cifs command several times, I don't get any folder already mounted kind of message. Though afterwards I can run umount the same number of times until I get error umount: /mount/point/: not mounted

Improve this question
9
  • 1
    Is the share shown in the output of mount or in /proc/mounts? What are the permissions for the domainname/username on the server? By the way, -o username=... is preferred to -o user=... Commented May 2, 2013 at 12:17
  • 1
    Well, yes it is: //server.name/sharename on /mount/point type cifs (rw) Commented May 2, 2013 at 15:32
  • 1
    What about the rights the user mounting the share has on the server (for the share)? Commented May 2, 2013 at 22:23
  • 1
    @peterph Well... Does it really matter? I mean I use the same username in both cases and in the case I run smbclient I can read the contents of the share (i.e. at least I have read rights) and in the other, under the same username, I can't. Commented May 3, 2013 at 6:34
  • 1
    Oh, forgot about that. I would check it nevertheless. Do you happen to have a Windows installation you could use to check it behaves the same on Windows? Commented May 3, 2013 at 8:50

2 Answers 2

Reset to default
1

smbclient is not mounting the share, "mount -t cifs ..." instead is doing this. You need to be superuser to mount shares. Could you please try sudo mount -t cifs //server.name/sharename /mount/point -o username=youruser,domain=yourdomain?

Improve this answer
4
  • 1
    If he didn't have root permissions the mount command would throw an error. Commented May 2, 2013 at 12:22
  • 1
    Yes, I've forgotten to say that I did it as root. Commented May 2, 2013 at 12:33
  • 1
    Could you please try the command (as stated above)? Differences to your command: "username" instead of "user", domain parameter separated.thanks Commented May 3, 2013 at 11:33
  • 1
    Well, I've tried, 'username' hasn't helped. Commented May 3, 2013 at 14:17
1

Finally I've solved the problem. Thanks to Wireshark.

From the Wireshark's logs I saw that when smbclient did its job then the peers exchanged GET_DFS_REFERRAL subcommands. But these messages were absent when I tried to mount the share with mount.cifs.

It seems the server uses Distributed File System facilities so I tried to add the support of DFS to the kernel and that made the trick. Now I can perfectly navigate, read and write in my mounted share.

Actually I thought that smbclient and mount.cifs used the same low-level instruments to connect to the SMB/CIFS servers but it isn't so. It looks like Samba can handle DFS itself without support of the kernel.

Improve this answer
1
  • 1
    It's not clear how you added support to DFS. Commented Mar 4, 2022 at 11:19

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.