CIFS Client Mount from one SAMBA/Windows Server allow for only one User?

[Zinky]

I've a SAMBA Server - smbsrv, serving out 2 shares named share_a and share_b. share_a is to be accessible only by user_a whilst share_b is to be accessible only by user_b.

On my 11.11 Client, I mount one share_a:

cifsmount //smbsrv/share_a /mnt_a -U user_a -P xxx -s

works fine. Now on to the next share_b.

cifsmount //smbsrv/share_b /mnt_b -U user_b -P xxx -s

Logging in User: You are already connected as user ->user_a<-


Is this the behaviour of CIFS Client?

[Steven E. Protter]

Shalom Nelson,

This is not the default behavior of CIFS.

It is possible that the user directive was used in /etc/opt/samba/smb.conf

If that directive is used on the share, it would explain the behavior.

Another possibility is that smb.conf is security=user and only one user is added with the smbpasswd -a command.

SEP

[Zinky]

Peace and Clean Earth SEP!

Tried it on just about all 11.0 and 11.11 CIFS CLient environments and CIFS Client behaves the same.. only one authenticated user can access a Samba/Windows service.

My SAMBA config is config'd correctly since a true Windows CIFS CLient can mount those shares properly and as seprate autheticated users - user_a and user_b.

[Steven E. Protter]

Shalom,

New possibility.

Bug in the cifsmount (CIFS client software)

Usually this gets fixed in new versions at http://software.hp.com

Could also be a server bug.

SEP

[Steven E. Protter]

Lastly before I go home late,

check the logs for help.

SEP

[eric roseme]

Hi Nelson,

Here is my guess.

You are logged in as root and trying to start 2 different sessions on the CIFS Server as root, but logging in as 2 different users. You cannot do that (even from a Windows client).

As root, do a mount for both cifs shares. Then start separate windows and do a cifslogin as each user. That may not accomplish what you actually want to do, but it will give you a clue as to the problem if it works.

I'll check back in tomorrow to see what happens (I am out of time today to test it on my systems).

Eric Roseme

[Eric Raeburn]

Hello, Nelson,

Eric from the CIFS Client lab here. Yes, the behavior you observe is correct and by design, but there are solutions.

First, limiting user_x to share_x can be done on the server side, or through the Unix permissions on one of the parent directories of the mount-point. The example you show won't work as is. If you want to separate the users' access rights on the client side, you would have to use a mount-point like /mnt/user_a/mnt_a, and then set the permission on the subdirectory "user_a" such that user_b cannot access it (the lowest-level directory of the mount-point becomes mode 777 and owned by root, while it is mounted, so you have to control access at a higher level).

Now on to the username issue...

There must be a one-to-one mapping between each local (hp-ux) login and each remote (cifs) login. You are attempting, as the local user "root", to be logged into a unique server as two different remote users. That is not supported.

Here is how to achieve your desired setup (this assumes that "root" on the hp-ux system is not one of the users who is going to access the Samba mounts).

1. As root, mount the two shares without logging in:

cifsmount -f //server/share_a /mpt_a
cifsmount -f //server/share_b /mnt_b

Note that if you are using CIFS Client A.01.xx, the "-f" must be placed on the command-line after the mountpoint. (We highly recommend upgrading to A.02.xx, btw. It is much improved.)

Or, the equivalent (and perhaps more straightforward):

mount -F cifs server:/share_a /mpt_a
mount -F cifs server:/share_b /mpt_b

2. Now, the two users must, AS THEMSELVES on the hp-ux system, do cifslogin. So if, as it seems from your post, you are trying to do this for them, using the -s option so they never have to actually do it themselves, you can become them via su(1). Assuming this, and that users a & b have the same hp-ux and cifs account names, as root do:

su user_a
cifslogin -s -P xxx server
exit

su user_b
cifslogin -s -P xxx server
exit

where, as above, if you are using an older client version, the command-line options must be at the end of the line (after "server").

If the the users' hp-ux and cifs account names are not equal, then the cifslogin command is:

cifslogin server username -s -P xxx

or for A.02, you can use:

cifslogin -s -P xxx -U username server

Of course, an alternate way to store user_a's and user_b's credentials is for them to telnet to the hp-ux system and perform cifslogin themselves. With CIFS Client A.02.xx, this can be done even if the server is not mounted. After the mounts are created, the users will have automatic access.

Please post your results so I can follow up with you if the outcome is not what you are seeking.

-Eric

[bfrench]

Eric,

I have the same problem. I get this error when attempting to us cifslogin after the mount are done.
cifslogin -s -P password -U username server
LOC: Netbios name lookup failure
LOC: Netbios name lookup failure


Do you know what would cause this error?

thanks,
Brian

[Eric Raeburn · Accepted solution]

Brian,

This is a different problem, a name-to-ipaddress resolution problem. The easiest was to work around this (without having to analyze the problem), would be to specify the server's ipaddress on the command line with either "cifsmount" or "mount" (this requires at least cifs client A.02.02, so if you have not updated to this version, there's your incentive; this version also has manpages, which you may find easier to use than the Admin Guide).

If you want to get a bit deeper into how name resolution works with the cifs client (so you can set things up so you don't have to specify the ipaddress as suggested above), have a look at pp. 37-38 here:

http://www.docs.hp.com/en/B8724-90079/B8724-90079.pdf

Please post your results. Thanks.

-Eric

[bfrench]

Eric,

Thanks for your help. My problem is now solved. Iâ m already using A.02.02, but I was not able to get IPaddress on the command line to work. I got the same error message as before. I think there may be some configuration problems within our DNS. I was able to add the host and IP to cifsclient.cfg. That worked great.

= {
ipAddress = "1.2.3.4";
}; # End of user-defined server section

Thanks for you help. I did not start this link but Iâ d like to give you 10 points. Iâ m not sure how thatâ s done?


Thanks again,
Brian

[Zinky]

Many thanks to the Sharity Team (or CIFS pointpersons) at H.P.!

May you continue to develop CIFS Client and may the HP-UX Community have an awareness that CIFS Client IS NOT SAMBA!

[Eric Raeburn]

Brian,

(1) I am concerned that specifying the ipaddress on the command-line did not work for you. We have tested that quite thoroughly. Please either post your results (i.e., the exact syntax you used) or file a defect report so we can look into it.

(2) Thanks, but I'm not interested in "points", so please don't spend any of your time figuring out how to give me any.

Nelson,

Thanks for your kind words.

-Eric

[bfrench]

Eric,

Here is what I did.
#
cifsmount ///Share_A /mnt/point_A -U -I <1.2.3.4>

#
This frist mount point worked fine.

cifsmount ///Share_B /mnt/point_B -U -I <1.2.3.4>
SRV: Invalid netname
#
The second mount point recieved the above error
---------------------------------------------

Here's some additional information

# bdf
/Share_A 2080000 0 2080000 0% /mnt/point_A

bdf: /mnt/point_B: I/O error


I hope this helps.

thanks,
Brian

[Eric Raeburn]

Hello, Brian,

There's no reason that shouldn't have worked. If you are interested in helping us persue this further, I would ask you to do the following. I would like to see the actual values you entered on the command line, rather than the dummy values you show in your example (that is, the actual server name(s), share(s), and ip address(es)). If you are not comfortable giving this in a public forum (quite understandable), please place a call with hp support, mentioning that Eric in the cifs client lab requested it.

If you want to continue here on the ITRC, it would also be helpful if you could attach a cifsclient logfile. Here's what to do (looks long, but should take just a few minutes):

(1) edit cifsclient.cfg such that the logLevels "nfsTrace", "cifsTrace", "smbSequence", and "nbnsTrace" are uncommented (remove the leading "#").
(2) enter "cifsclient restart"; note the process id
(3) redo the cifsmount commands such that the failure occurs
(4) enter "cifsclient stop"
(5) post your results (a cut-and-paste from your console would be ideal) and attach the cifsclient logfile: /var/opt/cifsclient/debug/client-log.pid, where pid is the process id noted in step 2
(6) edit cifsclient.cfg again, and comment out the logLevels you enabled in step 1 (logging is expensive--it slows the daemon considerably)

Having your exact commands, along with the logfile, will help us determine if we have a bug. Whether we try to figure this out here or via a support call, that's the info we'll need.

One last question: have you used the network analysis tool "ethereal"? Are you comfortable with it? We probably won't need it, but I'm asking just in case.

Thanks for your help,
-Eric