Red Hat Bugzilla – Bug 134570
smbmnt and smbumount fail to handle SMB mounts with 32-bit uid and gid parameters
Last modified: 2014-08-31 19:26:41 EDT
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
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.
smbmnt mounts the share with 16-bit truncated UIDs/GIDs.
smbumount says that "You are not allowed to umount foo"
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)
Credit for the smbmnt part of the patch goes to
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
I was able to sucessfully mount SMB shares with CIFS using 32-bit UIDs
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
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
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.