On 12/04/13 17:21, Rowland Penny wrote:
On 12/04/13 12:48, steve wrote:
On 12/04/13 13:10, Rowland Penny wrote:
On 12/04/13 08:32, steve wrote:
On 12/04/13 08:06, steve wrote:
On 11/04/13 22:45, steve wrote:
On 11/04/13 22:05, Rowland Penny wrote:
On 11/04/13 20:42, steve wrote:
On 11/04/13 20:39, Rowland Penny wrote:
On 11/04/13 17:27, steve wrote:
Hi again
This is driving me crazy!
If I change the permissions on the cifs share to 0777, I can then
write to the cifs share as user steve2 BUT the uid:gid sent by cifs
are wrong:
-rw-r--r-- 1 3000032 20513 0 Apr 12 09:25 j2
-rwxrwxr-x+ 1 3000017 users 0 Apr 12 09:25 j3
The file j2 was created on the unmounted share with the correct
uid:gid, 3000032:20513
The file j3 was created on the cifs mounted share. The server has
sent 3000017:100 :(
Any ideas?
Cheers,
Steve
OK Steve, after some investigation, either I am going mad ( possible
:-) ) or cifs is broken if you do not use winbind.
I can mount (via a script run at login) the users directory from the
server provided I do not use 'multiuser' but any files are created
on the server with the WRONG uid i.e. the user I login with is uid
3000017, if the permissions on the client are checked the file
belongs to the user, but if checked on the server, the files do not
belong to the user, they belong to a uid '3000000'.
I do not know where this user comes from, getent passwd on the
server does not show this user, but if I create a testdir on the
server I can chown it to 3000000.
If I try to mount the users directory using multiuser, the mount
fails because it now requires roots/Administrators krb5_cc and I
have not created it.
I am now coming round to the idea that if the samba team want S4 to
be used with unix clients then some work needs to be done to ensure
it easily works as expected and in my opinion the first thing that
needs to happen is the S3 winbind that exists at present needs to be
thrown into the wastebin.
Rowland
Hi Rowland
It WAS an idmap/winbind problem. On the one hand we can get our
uid:gid from idmap.ldb or we can get it from AD. But not a mix of the
two. What I had was the server using idmap and the client using AD.
Disaster! The line:
idmap_ldb:use rfc2307 = Yes
needs to be added to smb.conf for uid:gid ALWAYS being pulled from
AD. Just to be sure, I also had a long ldbedit session on idmap.ldb
to remove the users that Samba added before I got the syntax right
for the smb.conf line above.
I agree that winbind is too complicated a way to go about adding
Linux clients to AD, especially when there are point and click
methods around (I believe you just found one: we use nss-ldapd). But
what really seems to confuse the issue is that we have TWO methods
for ID mapping. idmap or the AD ldap. I'd vote for going with just
one method: AD. Having choice in matters such as these can only add
to the already confusing winbind/AD setup, as I have just so
painfully found out:(
I believe the devs think that as time goes by, Samba4 will get more
attention from companies wanting to deploy more and more windows
boxes. Where I come from, we're going the other way: even though
we'll always cater for a few microsoft programs, the windows boxes
are slowly but surely being replaced by Linux. Maybe in a year or so,
none of this will be relevant as we go cloud. Not sure. Having said
all this, I still think S4 is a remarkable achievement.
Cheers,
Steve
Hi Steve
That may have been your problem, but it wasn't mine :-(
I had that line in smb.conf, but the users directory was mounted on
the client and the files etc belonged the correct user whose uidNumber
was 3000017 but all newly created files became the property of
3000000, both on the client & the server. I could not find the user
3000000 anywhere, so I went and read your postings over on the cifs
mailing list to see if it gave me any ideas, it did :-) .
I found the problem & user 3000000 in /usr/local/samba/private/idmap.ldb
# record 24
dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_BOTH
xidNumber: 3000000
distinguishedName: CN=S-1-5-32-544
A bit more googling produced this:
SID: S-1-5-32-544
Name: Administrators
Description: A built-in group. After the initial installation of the
operating system, the only member of the group is the Administrator
account. When a computer joins a domain, the Domain Admins group is
added to the Administrators group. When a server becomes a domain
controller, the Enterprise Admins group also is added to the
Administrators group.
I had added my user to the Domain Admins group, so, using samba-tool,
I removed him again, chown all the users files etc on the server to
the user and rebooted the client.
YEAH it works!!!!
OK, how did my users uidNumber become the same (but seemingly only
when saving files on a cifs mount) as a group number by just joining
the group via samba-tool?
Rowland
Hi Rowland
Good to hear you got it going. Yeah, it's BUILTIN\Administrators here
too. I think it is everywhere, like the rid 500 for Domain Admin.
wbinfo --uid-to-sid=3000000
S-1-5-32-544
wbinfo --sid-to-name=S-1-5-32-544
BUILTIN\Administrators 4
I still think you'll need the cifs multiuser option, otherwise all files
created in the mount will _always_ be owned by the user who made the
mount in the first place. You'd need pretty open permissions for
everyone to work and edit files within the share if only one user is to
own all the files. Maybe that's OK for you but we have to have files
editable only by their owner, and that owner can be any user who has
access to the share. In our case, the unix home folders. IOW, where you
are just after you log in.
Cheers,
Steve
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
