Hello, we (SuSE Linux 9.1, Samba 3.0.9-2.6 on the server, Samba 3.0.9 and 3.0.11 on the clients) have this share to allow my boss access to his secretary's home directory: [home_secretary] path = /home/secretary browseable = no force user = secretary valid users = boss, myself read only = no This should allow two people to access /home/secretary *as* user "secretary". However, when we 'smbmount' this share, the UNIX extensions seem to kick in and locally we are presented with secretary's UID/GID as they are on the server, which prevents writing to the directory, although the access rights *should* allow it. Mounting the share from Windows or via KDE's "smb://" protocol (which does not support UNIX extensions) works fine. The logs also show no errors, just login success. This could be solved by allowing disabling the UNIX extensions from the client side, but a) that would yet have to be implemented and b) that way you'd also lose symlinks and access rights, which is not a good idea. Thank you, Jens
Just noticed, this also happens when I'm *not* using "force user". Mounting a share on a server which uses different UID/GIDs than are used locally, with UNIX extensions enabled, will make Linux locally believe that the user has no access rights, although the Samba authentication works fine and the user *should* be able to access the share fine. For example: # /etc/samba/smbfstab //filebox/home /home/RZ-home cifs username=jbenecke,password=XXXX,rw this mount succeeds, but is unuseable: drwx------ 4 2083 10850 0 2005-02-02 10:55 RZ-home > LC_ALL=C touch RZ-home/file touch: cannot touch `RZ-home/file': Permission denied > id uid=501(jens) gid=100(users) One possible way to solve this problem would be to specify (if mounting as root) the UID/GID to *override* on the server side, even if UNIX extensions are used. Just disabling UNIX extensions for the client will also disable symlinks and so on, so is not really a solution. A more elegant solution would be to create a UID/GID mapping scheme. Thanks, Jens
Can you retest with the cifs fs ? We don't actually support smbfs. You would need to talk the kernel maintainers. However, cifs fs is under more active development. See http://linux-cifs.sf.net/ for details.
Hi, well if you read the smbfstab above, I *am* using CIFS, not SMBFS. Here is the mount status: //filebox/home on /home/RZ-home type cifs (rw,mand)
well then you are using smbmount :-) Since that is only used with smbfs. And it would help to file the bug against the correct product. :-)
OK, because this also happens when mounting normal shares, without "force user", I changed the subject accordingly. Is anybody investigating this? Thanks!
Before starting to prototype a solution, I would like to understand the uid mapping now done in Linux for NFSv4 client. Although I doubt that this facility could be reused directly, that needs to be verified.
Hi, is this bug still being investigated? I'd like to know if I can help in any way. Thanks!
Hello, sorry for my English, i am using Debian 3.1 server & clients when i mounting shares whith username sergu1 (UID=1005 GID=1003 on server) in /etc/fstab //SFLABS/sergu1 /home/serg/sergu cifs iocharset=koi8-r,ip=192.168.128.1,user=sergu1,password=**** after mounting serg@gamma:~/sergu$ mkdir ttt serg@gamma:~/sergu$ ls -l drwx------ 2 1005 1003 0 2006-03-15 23:50 ttt serg@gamma:~/sergu$ rmdir ttt serg@gamma:~/sergu$ touch ddd touch: cannot touch `ddd': Permission denied On mounting system I can create diretory, but no file. Is any way to perform UID mapping on mounted system?
We now run into the same problem. After upgrading our LinkSys NAS to new firmware, now there runs a samba 3.0.x server for the SMB shares (previously samba 2.2x). We have user shares mounted with automount into the users home dir. Since the update now, the files and directories now cannot be writen/created anymore as the uid/gid are different. This problem doesn't occur with our other server<->client-combinations, as we have yp/nis running, so all "normal" system use the same uid/gid. Using a nativ windooze client (w2k/xp etc.) all running normal. Using KDEs kio also is ok (as i read, it doesn't understand the Unix extensions). Our workaround now is to create a gid on network identical to the gid used on the NAS and assigning it to the users who mount the NAS shares. So they can write/create files. But i think this isn't what we all want. There should/must be a uid/gid mapping mechanism. Maybe based on the user/group NAME. Using the uid=xxxx,gid=xxxxx option on the mount.cifs command line doesn't help. We are using samba 3.0.23d on the servers/clients. mount.cifs varies between 1.10-3.0.23d-0.1.38-1074:1075-SUSE-SL9.3 on the SuSE 9.3 clients and 1.10-3.0.23d-5.1.39-1084-SUSE-CODE10 on the SuSE 10.x. The LinkSys NAS now runs samba 3.0.20. The automount options are similar to: -fstype=cifs,credentials=/home/xyz/.mnt/login.txt,uid=xyz,iocharset=utf8,codepage=cp8 50 \\\\nas01\\& There seems to be a identical bugid 4287
(In reply to comment #1) > Mounting a share on a server which uses different UID/GIDs than are used > locally, with UNIX extensions enabled, will make Linux locally believe that > the user has no access rights, although the Samba authentication works fine > and the user *should* be able to access the share fine. You can use the "noperm" mount option, which disables enforcement of Unix permissions and ownership on the local side.
Yes, noperm may be the best option here for now. Eventually we'd like to add some sort of ID mapping to cifs but it doesn't exist today.
Looking into this. What sort of ID mapping can be used. For example, if I login as user xyz (-o user=xyz) but user xyz on the server and client have different ids (uid) or gids on server and client have different group names, what kind of mapping you do? It is also possible that the same group exists on server and client but gid of the group on the server is taken up by a different group on the client.
I am not sure whether any kind of uid mapping is going to help. When you have user mounted shares, they are mounted as if with mount option uid=1234 and gid=5678 of that user=abcd. And I do not understand what it means uid/gid mapping here, are uid/gid from the server are mapped to uid/gid on the client? With uid= specified on the mount command for user mounts, not sure whether any uid/gid (server) to uid/gid (client) mapping will help.
Regarding comment #8, inspite of the warning about permission denied while doing 'touch ddd', the file does get created on the server, it just can't be modified by the user 'serg' (metadata modification fails, file can't be written to) in any way.
(In reply to comment #13) > I am not sure whether any kind of uid mapping is going to help. > When you have user mounted shares, they are mounted as if with mount option > uid=1234 and gid=5678 of that user=abcd. > And I do not understand what it means uid/gid mapping here, are uid/gid > from the server are mapped to uid/gid on the client? > With uid= specified on the mount command for user mounts, not sure whether > any uid/gid (server) to uid/gid (client) mapping will help. > idmapping is going to be tricky... It's somewhat easier with NFSv4 since it sends text user id's across the wire and then the receiving side can determine how to map that to a local uid. CIFS unix extensions send a numeric uid however (in response to a QPathInfo call for instance). So to do some sort of uid mapping you need to: a) query the server somehow and ask "to what username does this uid map?" ...and then upcall to userspace somehow and ask: b) "what's the local uid for this username?" With that you could then write an inode "permission" op that could enforce permissions locally. The catch here is that no call for "a" exists yet, so you'll need to extend the protocol. A much better plan IMO would be to implement multi-session mounts: http://wiki.samba.org/index.php?title=LinuxCIFS_Multisession_Mount ...and just leave permissions enforcement to the server altogether. That's a much bigger project however.
(In reply to comment #15) > (In reply to comment #13) > The catch here is that no call for "a" exists yet, so > you'll need to extend the protocol. perhaps if a (Samba) server supports named pipes like lsarpc and samr, may be winbindd can/does identify a user name for a given uid/sid. Thus it may not be necessary to extend the protocol.
The current cifs client now supports multiuser mounts with both krb5 and username/password based authentication. I think that's as good as a solution as you're going to get with this, given the protocol limitations. At this point, I'll go ahead and close this as RESOLVED FIXED based on that, but feel free to reopen and we can discuss it further if you like.