Description of problem: When 32-bit UIDs and/or GIDs are used when mounting or unmounting a SMB share to/from the filesystem, smbmnt/smbumount use the 16-bit truncated version of the UID and/or GID inappropriately. Version-Release number of selected component (if applicable): As far as I can tell, all versions of samba up to and including 3.0.8pre1 How reproducible: Always Steps to Reproduce: 1. Attempt to mount a SMB share with a 32-bit UID or GID. Or, if using a patched smbmnt, attempt to unmount said mount as the non-root original mounting user. Actual results: smbmnt mounts the share with 16-bit truncated UIDs/GIDs. smbumount says that "You are not allowed to umount foo" Expected results: smbmnt mounts with the provided 32-bit UID and/or GID smbumount is able to successfully unmount a SMB share as a 32-bit current user that was the original mounter (assumes that the share was mounted with a patched smbmnt) Additional info: Credit for the smbmnt part of the patch goes to http://lists.samba.org/archive/smb-clients/2004-March/000384.html. I wrote the smbumount patch myself in a way that should be backward-compatible with kernels that don't support 32-bit UIDs.
Created attachment 104735 [details] 32-bit UID/GID patch for smbmnt and smbumount
Created attachment 104737 [details] Modified RPM spec file for 3.0.8-0.pre1 that I'm currently using on my system Added in case if anyone seeing this bug desperately needs to get 32-bit UID/GID support working and knows how to build an RPM. Of course, if this patch goes into the actual Fedora Samba package, it will probably be pre2 or something like that and not pre1sl1 ;-). To build the patched RPM, run `rpm --install samba-3.0.8-0.pre1.src.rpm` as root (download from the Development repository), copy this samba.spec into /usr/src/redhat/SPECS, download samba-3.0.8-32bit-uidgid.patch to /usr/src/redhat/SOURCES, cd into /usr/src/redhat/SPECS, and run `rpm -ba samba.spec` as root. When complete, go into /usr/src/redhat/RPMS/i386 (or whatever your arch is) and run `rpm --upgrade samba-*.rpm` as root.
Smbfs has been depreciated in favor of cifs, which has upstream maintainers, active development, and related goodness. Try using mount -t cifs instead. If cifs doesn't work with 32-bit UIDs, let me know.
I was able to sucessfully mount SMB shares with CIFS using 32-bit UIDs and GIDs. Unfortunately, I am not sure how to mount arbitrary (not in /etc/fstab) SMB shares as a user with the ability to unmount as that user in the same way that smbmount/smbmnt and smbumount do. I'm guessing that I can add myself to sudoers with the ability to mount and unmount arbitrary shares, though I'm wondering if an easier method exists. I'm also using a non-Fedora package smb4k (http://smb4k.berlios.de/) to mount and unmount shares, and it doesn't support CIFS yet. It's a super-convenient program for mounting and unmounting SMB shares. GNOME's built-in support for using SMB shares doesn't work for me (I'm not sure how I can have it automatically use my credentials across the entire network; it looks like I have to log into each share with my domain credentials for every share that I want to look at. None of our internal shares are anonymously available, so if I don't log in, I don't see anything). I can live without smb4k if an easy-to-use graphical replacement exists, such as if Nautulus has some configuration screen that I missed that lets me enter in authentication credentials for SMB. Perhaps smb4k could be modified to use CIFS instead of smbfs and maybe use the sudoers approach or something similar. Because SuSE has the smbmnt part of the patch in their product, it would be nice if Fedora also applies this fix even though it's a deprecated filesystem. Because it's deprecated, there shouldn't be much to lose by landing the patch into the RPM, in theory. I agree that CIFS is the preferred method going forward as a +s smbmnt and smbumount could be a potential security hazard when compared to a sudoers-controlled SMB mounting strategy. For the short-term, however, I plan to continue using smb4k in my work-flow, so I'm hoping that this patch can be applied even though it's a deprecated filesystem. Please? Pretty please :-)? It would save me from having to recompile from the SRPMS with each samba package release. Or, if you have any suggestions on mounting arbitrary SMB shares as users within a GUI using CIFS, please let me know.
I included your patch in the Samba rpms I made yesterday. Grab them from rawhide and see how well they work.
I tried it out and it works :-)! Thank you very, very, very much for including the patch :-)!! I also ensured that I could not smbumount another user's share, and that worked properly as well. smbumount-ing a smbfs share mounted with a 32-bit uid works when done by root or the mounting 32-bit uid. Thanks :-), and also thank you for the suggestion about using cifs. I will probably continue to use smb4k and smbfs for a while, and I'm looking forward to using cifs in the future and its ACL goodness across all users rather than on a user-by-user basis.