Automounting Windows Share using user's kerberos ticket
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
0ddba11:
Despite being something you'd think would be relatively simple, there's a huge amount of complexity behind the scenes getting all this to work, so without more information, there's only so much I can suggest.
Check the patch on the Red Hat bug report with the absolute latest cifs.upcall source from the master branch from samba git. The guy assigned that bug report is also a samba developer and the maintainer of the cifs.upcall source, and I know he made multiple commits addressing this problem, so it's possible that patch is not the latest in the samba master.
You might consider logging in as root (or another local user) and removing all kerberos tickets from /tmp so that all the tickets are recreated as each user in kerberos logs on again. This may help to eliminate any potential permissions issues, as if the tickets aren't accessible for the user trying to authenticate to the share, then the mount is obviously going to fail as the kerberos client can't read the ticket.
Try using -v judiciously to determine exactly what is being passed to the kernel from mount.cifs (see previous posts). Try the uid/gid parameters to determine if it is a likely kerberos/permissions issue, or something else. You might need to resort to strace to try and trace exactly what is going on as the mount call proceeds (and eventually fails).
These are all kind of generic, but they should point you in the right direction, and perhaps help to obtain some more useful debugging data.
Number Two
I have now implemented a different (and I think more appropriate solution) using the pam_mount module.
I'd never seen this pam module before, and when I read what it does I couldn't believe my eyes - it mounts volumes when a user starts a session and unmounts them when their session ends!
Perfect.
Whilst an RPM wasn't available for Red Hat 4 I found some extra packages for Cent OS 4 here: http://centos.karan.org/el4/extras/stable/ which install and run just fine on RHEL4. (remember to get both the 32 bit and 64 bit RPMS if you're running a 64 bit system as some 32 bit apps like Exceed onDemand need the 32 bit pam_mount.so)
For those who are interested, here is my /etc/security/pam_mount.conf:
The 'mkmountpoint 1' line means that the mount points get created automatically
On the 'volume' line '&' gets replaced with the current user
uid=& makes the current user the owner for all files and directories
Setting filemode and dirmode 0700 means that only the owner ends up with permission to it, which stops user B accessing a share that user A has mounted.
I just finished reading about pam_mount and it sounds absolutely perfect, not to mention being a more elegant solution than the autofs kludge I was going to put together. Thanks a bunch for enclosing your detailed configuration information and explanation, it should be a major time saver!
Unfortunately, while the Red Hat patch is good news, it doesn't apply to me as I'm using the unofficial SerNet Samba binaries for CentOS 5 that upgrade the Samba packages to 3.2 (as well as having RPMs for 3.3 and 3.4 available). The reason for this is the 3.2 branch is the earliest Samba branch that supports certain features I need, in particular SMB signing.
Fortunately, the relevant fix for cifs.upcall is simple and can easily be patched into the 3.2 source and compiled with the included SerNet SRPMs. Of course, this is fairly tedious and a time sink, as it really ought to be done each time the packages are upgraded (even if you can get away with not doing so). I might see if I can convince SerNet to backport the fix into their packages, otherwise, the SRPM recompiles will have to continue.
Still, the pam_mount solution sounds excellent, so thanks again for reporting back. Also, I hope you enjoy your Christmas holiday
Now the uid is equal to the uid of the user share we want to mount, which means the ticket is now being retrieved as the actual user logging in which gets rid of the error 126 in my case.
Now, when user daenney with uid 10005 logs in the following is being called:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.