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 ......
*** Bug 1000 has been marked as a duplicate of this bug. ***
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.
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.
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
The same problem occurs in Debian testing/unstable: kernel 2.6.4 Samba 3.0.2a-Debian glibc 2.3.2
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)
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.
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.
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
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).
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).
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).
Created attachment 635 [details] fix some mistakes on patch 626. Some mistakes on patch 626 were corrected.
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.
(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.
workaround is described here, smbfs is unmaintained anyway, sorry. *** This bug has been marked as a duplicate of 1920 ***
*** Bug 1691 has been marked as a duplicate of this bug. ***
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.
*** Bug 2392 has been marked as a duplicate of this bug. ***
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.
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