Bug 999 - smbmount unable to use uid and gid options with kernel 2.6
Summary: smbmount unable to use uid and gid options with kernel 2.6
Status: RESOLVED DUPLICATE of bug 1920
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: smbmount (unmaintained) (show other bugs)
Version: 3.0.1
Hardware: x86 All
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact:
URL:
Keywords:
: 1000 1691 2392 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-01-23 05:46 UTC by Christophe Borivant (550 5.1.1 Recipient address rejected: User unknown in local recipient table)
Modified: 2007-07-09 14:06 UTC (History)
5 users (show)

See Also:


Attachments
proposed solution to fix the issue. (2.19 KB, patch)
2004-08-27 11:49 UTC, Haroldo Gamal
no flags Details
Make kernel 2.6.8.1 use the uid/gid/file_mode/dir_mode given by the user (5.65 KB, patch)
2004-08-31 15:48 UTC, Haroldo Gamal
no flags Details
Complements the kernel patch sent before. (1.99 KB, patch)
2004-08-31 15:52 UTC, Haroldo Gamal
no flags Details
Patch smbmount as sugested on my last patch. (1.66 KB, patch)
2004-09-01 13:07 UTC, Haroldo Gamal
no flags Details
fix some mistakes on patch 626. (6.28 KB, patch)
2004-09-01 13:08 UTC, Haroldo Gamal
no flags Details
updated smbmount patch for correct user mount handling (3.96 KB, patch)
2007-07-09 14:06 UTC, Steve Langasek
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Borivant (550 5.1.1 Recipient address rejected: User unknown in local recipient table) 2004-01-23 05:46:12 UTC
OS Gentoo Linux glibc 2.3.2 gcc 3.2.3 
When i try to mount a share with uig and gid option, the uid and gid  mapping 
doesn't work. I get the original uids and gids from the server. 
This prevent me to write in the share. 
 
When I do the same thing but running a 2.4 kernel instead of a 2.6, everything 
is perfect. 
I first thought it was because the glibc and gcc had been compiled against 2.4 
kernel headers. But I updated my kernel headers, recompiled glibc, gcc and 
samba, and the problem still occurs. 
 
Hope i'm in the right place because it's my first bug report ......
Comment 1 Gerald (Jerry) Carter (dead mail address) 2004-01-26 10:33:17 UTC
*** Bug 1000 has been marked as a duplicate of this bug. ***
Comment 2 Christophe Borivant (550 5.1.1 Recipient address rejected: User unknown in local recipient table) 2004-01-26 10:47:47 UTC
Some more information : 
The server is a Redhat Enterprise Linux 3 ES with those packages installed : 
samba-common-3.0.0-14.3E 
samba-3.0.0-14.3E 
samba-client-3.0.0-14.3E 
The server is a domain member. 
Users are authenticated on an openldap directory. 
PAM has been configured on the samba server to allow authentication on the 
ldap server. 
Comment 3 Christophe Borivant (550 5.1.1 Recipient address rejected: User unknown in local recipient table) 2004-01-27 07:42:23 UTC
I've been able to reproduce the problem on a very simple configuration.  
Both server and client sides are on my laptop and I use version 3.0.1.  
Here is the server configuration :  
# Global parameters  
[global]  
        workgroup = DSI  
        server string = Samba Server %v  
        passwd program = /usr/bin/passwd %u  
        passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n  
        unix password sync = Yes  
        log file = /var/log/samba/log.%m  
        max log size = 50  
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192  
        dns proxy = No  
  
[homes]  
        comment = Home Directories  
        read only = No  
  
On the client side, I try to do this connected as root:  
smbmount //localhost/borivant /mnt/test -o  
username=borivant,uid=oracle,gid=dba  
  
Once mounted an ls -l /mnt/test should show each files and directories  
belonging to oracle from the dba group.  
  
That's ok when running a 2.4 kernel but not when running a 2.6 kernel.  
I tried to mount shares the same way against a 2.2.8 samba server and I have  
no problem.  
So the problem seems to be only against a samba 3.0.x server.  
Comment 4 Justin Frisch 2004-02-05 05:23:56 UTC
Server: Gentoo Linux, gcc 3.2.3, samba 3.0.1-r1 (compiled via emerge) 
Local:  Debian Linux, gcc 3.3.2-2, samba 3.0.1-2, KDE 3.1.95, Quanta 3.1.95 
(installed via apt-get) 
 
Problem: In addition to permissions being listed and shown incorrectly, also 
may be possible loss of data when saving files without permission. 
 
Scenario: 
1. Quanta web editor used to update a CSS file for a customer. 
2. File opened and edited. 
3. File saved, permission denied. 
4. File on server is now empty. 
 
Requirements: 
1. Permissions to access file locally, but not save locally. 
2. Permissions to access and save file remotely. 
 
Local ls: 
-rwxrwxr-x    1 81       apache          0 2004-02-05 14:14 css.class.php.bak 
 
Server ls: 
-rwxrwxr-x    1 apache   apache          0  5. Feb 14:14 css.class.php.bak 
 
User is listed as a member of group apache on both Local system and Server. 
 
This could possibly be a grave problem for some people, luckily for me at the 
time this originally happened I had could save a copy locally and also had a 
backup of the original. 
 
Hope this helps a little. 
 
Justin T 
Comment 5 Valery L. Lourie 2004-03-22 03:25:12 UTC
The same problem occurs in Debian testing/unstable:
kernel 2.6.4
Samba 3.0.2a-Debian
glibc 2.3.2
Comment 6 Nathan Stocks 2004-07-13 10:00:28 UTC
I am having the same problem--I have samba 3.0.4 on a Gentoo Desktop (2.6
kernel) and a Gentoo Server (2.4 kernel).  The uid=<arg> and gid=<arg> are
ignored, making my smbmounted share unusable.

Desktop                Server
---------              ------------
Gentoo, 2.6.x kernel   Gentoo, 2.4.x kernel
samba 3.0.4            samba 3.0.4
AMD Athlon 1800+       Intel Xeon 2.8 GHz

When I use smbmount on the desktop to try to mount a share on the server, the
server uid and gid's are preserved whether I use the uid/gid options or not, and
my desktop system takes the server uid,gid #'s and maps them to local users/groups.

Example output: (uid 1000 = nathan on my desktop, gid 100 = users on my desktop)

root@mydesktop nathan # smbmount //myserver/myshare localdir/ -o \
                        username=testuser,uid=1000,gid=100                     
     
Password:
root@mydesktop nathan # ls -aln localdir/
total 8388620
drwxr-xr-x    1 1000 100 4096 Jul 13 10:26 .
drwx------  125 1000 100 8192 Jul 13 10:24 ..
drwxr-xr-x    1 1002 100    0 May  4 11:25 delete_me_soon
drwxr-xr-x    1 1002 100    0 May 14 12:00 nathan
drwxr-xr-x    1 1002 100    0 Jun 24 11:42 pbhtml
drwxrwxr-x    1 1002 100    0 Apr 28 10:20 tools
-rwxr-xr-x    1 1002 100  180 Jun 24 15:19 README
root@mydesktop nathan #

I executed these commands as root.  The actual permissions on the "localdir"
directory got set correctly (1000,100), but the rest of the files in the
directory have the same uid & gid numbers as they do on the server (they happen
to have the same group number on the server, but that's just because the users
group defaults to gid 100 on all Gentoo systems)
Comment 7 Jürgen Markmann 2004-07-16 06:42:46 UTC
I'm also having the same problems.

Server and Client:
Operating System: Fedora Core 2
Kernel: 2.6.6-1.435.2.1
Samba version: 3.0.3-5

The uids and gids in the mounted samba share are always the ones of the server.
The smbmount command completey ignores any "uid=" and "gid=" options. As root on
client side, with the smb account data of a normal user on the server, I could
even delete a file which was owned by root on the server. I think this is quite
critical.
Comment 8 Pawel Sawicki 2004-07-19 14:21:48 UTC
My server/client machine:
 + Kernel: 2.6.6-1.435.2.3
 + Samba: 3.0.3-5
 + Linux distribution: Fedora Core 2

I've had the same problem.

Since I desperatly needed a working solution I've prepared a workaround that
suits my needs for the time being. Hopefully there are only a few computers
running 2.6.x kernel in the network I'm responsible for so the problem isn't so
critical in my situation.

My temporary patch:

Server side:

chown -R someServerUser:someServerGroup /some/shared/directory
find /some/shared/directory -type f -exec 0660 {};
find /some/shared/directory -type d -exec 2770 {};

# the numerical value of the 'someServerGroup' is eg. 1234
# '/some/shared/directory' is shared as 'simpleShare'

Client side:

groupadd -g 1234 someClientGroup

Now set that 'someClientUser' is a member of 'someClientGroup' ('vim
/etc/groups' should be just fine).

Next, after you smbmount the 'simpleShare' somewhere on your filesystem
'someClientUser' will have full 'RW' access to it.

As I said - this is only a workaround! I'm lloking forward for the real solution.
Comment 9 Haroldo Gamal 2004-08-27 11:49:08 UTC
Created attachment 621 [details]
proposed solution to fix the issue.

I have compared the kernel versions 2.4.22 and 2.4.26 and found the problem in
the file fs/smbfs/proc.c.
The function smb_decode_unix_basic simply ignores the uid and gid specified
during mount.
To keep compatibility with the old behavior, the patch solves the problem when
uid/gid are specified and different than 0.
The patch serves to show where the problem is located, I think the creation of
a new mount parameter would be a better idea.

Haroldo Gamal
Comment 10 Haroldo Gamal 2004-08-31 15:48:37 UTC
Created attachment 626 [details]
Make kernel 2.6.8.1 use the uid/gid/file_mode/dir_mode given by the user

This patch must be applied over kernel 2.6.8.1.
To fully work the smbmnt.c must be patched too (next patch I have sent).
Comment 11 Haroldo Gamal 2004-08-31 15:52:50 UTC
Created attachment 628 [details]
Complements the kernel patch sent before.

This patch makes smbmnt only to specify the params given by the user.
This behavior will be only true for kernels 2.4 or greather.
The smbmount.c file must be patched when user wants to set uid or gid to root
(0).
Comment 12 Haroldo Gamal 2004-09-01 13:07:46 UTC
Created attachment 634 [details]
Patch smbmount as sugested on my last patch.

This patch modify smbmount to only pass to smbmnt the uid, gid, file_mode and
dir_mode specified by user.  Even when uid and gid equals to root(0).
Comment 13 Haroldo Gamal 2004-09-01 13:08:27 UTC
Created attachment 635 [details]
fix some mistakes on patch 626.

Some mistakes on patch 626 were corrected.
Comment 14 Botykai Zsolt 2004-09-29 11:10:08 UTC
I had the same problem with one Gentoo workstation (samba v3.0.7) and a Fedora
server (3.0.5pre1-0pre1.0).
Solution for me:
Just added "unix extensions = no" to the servers smb.conf and the uid, gid,
fmask, dmask works fine now.
Comment 15 Jürgen Markmann 2004-10-06 10:14:41 UTC
(In reply to comment #14)
> Just added "unix extensions = no" to the servers smb.conf and the uid, gid,
> fmask, dmask works fine now.

Thank you very much. This worked for our network too. But I think it's still a bug.
Comment 16 Björn Jacke 2004-10-19 15:03:31 UTC
workaround is described here, smbfs is unmaintained anyway, sorry.

*** This bug has been marked as a duplicate of 1920 ***
Comment 17 Björn Jacke 2004-10-19 15:30:37 UTC
*** Bug 1691 has been marked as a duplicate of this bug. ***
Comment 18 Haroldo Gamal 2004-11-18 12:29:06 UTC
This bug is fixed under kernel 2.6.10-rc2-mm2.

Without the patches over smbmount and smbmnt, it is not possible to get the uid,
gid, fmode and dmode assigned on the server.
Comment 19 Jan 2005-03-08 10:58:12 UTC
*** Bug 2392 has been marked as a duplicate of this bug. ***
Comment 20 Steve Langasek 2007-07-09 14:02:32 UTC
Patch #634 has the problem that if a user mounts a Unix-aware share with
smbmount, they can be caught in the situation of being unable to access
files on that share due to the *local system's interpretation* of the
filesystem permissions.

Patch that fixes this (treating all user mounts as having an implicit
uid=getuid() option) will be forwarded shortly.

Note that mount.cifs has the same problem; I'll open a new bug about
that.
Comment 21 Steve Langasek 2007-07-09 14:06:36 UTC
Created attachment 2801 [details]
updated smbmount patch for correct user mount handling

Update to the previous patch, to ensure that users who mount shares with smbmount will be able to access the contents of the mount points afterwards in spite of server Unix extension support and permission mappings