Hi 

found the bug i am french :) i have accent on the name of user and group 
when smbcacls add SID group with accent on the name it work but when the SID is
for the user account it break i have no acls :
 getfacl test 
# file: test
# owner: f
# group: root
user::rw-
group::r--
other::r--


If i make with smbcacls -a it work  .

I think the probléme is for user who have accent I don't know why it can't add acls.
if it can with  smbcacls -a it can normaly with smbcacls -S 

thanks

Sorry, I don't exactly understand where you see a bug in smbcacls. 

I can add groups either with their name (containing non-ascii chars like german
umlauts) or by sid with either -a or -S.

Hi,

When the name of user is containing non-ascii chars,  it can't add acls so it
makes just acls for owner .

 getfacl test 
# file: test
# owner: f
# group: root
user::rw-
group::r--
other::r--

The group who  contains non-ascii chars  works .

If  i add a list of acls whose group possess a non-ascii chars, it works but if
i have a SID for user who contain non-ascii char on this list,  adding acls
don't  work .

So to resumm , adding a 'non asscii' group works but not a 'non asci' user
adding is not working ( can't create acl).

If i use adding acl attribute line by line with option -a for each 'non ascii'
user, it works  but  it's too long , we prefer to use list of user  instead.

 
thanks.
(In reply to comment #2)
> Sorry, I don't exactly understand where you see a bug in smbcacls. 
> 
> I can add groups either with their name (containing non-ascii chars like german
> umlauts) or by sid with either -a or -S.

Hi,

When the name of user is containing non-ascii chars,  it can't add acls so it
makes just acls for owner .

 getfacl test 
# file: test
# owner: f
# group: root
user::rw-
group::r--
other::r--

The group who  contains non-ascii chars  works .

If  i add a list of acls whose group possess a non-ascii chars, it works but if
i have a SID for user who contain non-ascii char on this list,  adding acls
don't  work .

So to resumm , adding a 'non asscii' group works but not a 'non asci' user
adding is not working ( can't create acl).

If i use adding acl attribute line by line with option -a for each 'non ascii'
user, it works  but  it's too long , we prefer to use list of user  instead.

 
thanks.
(In reply to comment #2)
> Sorry, I don't exactly understand where you see a bug in smbcacls. 
> 
> I can add groups either with their name (containing non-ascii chars like german
> umlauts) or by sid with either -a or -S.

Hi,
i have understood a part of the problem around "non ascii char" user , when i
give the acl of a user (non ascii char), it could work when system creates a
group:: for the user   
at example:

getfacl test 
# file: test
# owner: f
# group: root
user::r--
user:papa:rwx
group::---
group:42:rwx
group:usb:rwx
mask::rwx
other::---
-> at this command , the result should be user::é:rwx for this group::42:rwx
When i do a 'getacl'command, i see the group:42:rwx (instead it should be
user::é) but
when i do " smbcacls  //localhost/u  test2 -U administrateur" , i can see the
right   user::é  associated to group:42 
ACL:DOMNT\é:ALLOWED/0/FULL

when smbacls generate acls for an non ascii user, by using a group  it will work
howewer if you try to generate acl for a non ascii user,  it tries to generate
user::...(something i think it doesn't  recover  SId  to right name of  user  ,
maybe trouble is around the research of sid to find uid ( the link between both
elements).
at example of a wrong configuration from system :

 group:42:rwx = user::é:rwx
 group::43:rwx = user::papaé:rwx

Hi,


If the name don't have non asscii char

  local_uid_to_sid:  uid (1585) -> SID
S-1-5-21-1688021309-183578045-1594628879-1069 (c).
[2004/11/25 18:27:32, 10] passdb/lookup_sid.c:uid_to_sid(323)
  uid_to_sid: local 1585 -> S-1-5-21-1688021309-183578045-1594628879-1069


If they have ascii char i can foundon the log:

  local_sid_to_uid: papaé found in passdb but getpwnam() return NULL!
[2004/11/25 20:04:27, 10] passdb/lookup_sid.c:sid_to_uid(392)
  sid_to_uid: local lookup failed


thanks

Well, I just double-checked:

smbcacls can 
* add acls for users containing non-ascii chars (as well as groups)
* either a single user, or a list of users 
* in either their name- or their sid-representation
* either given as a comma-separated list or line-by-line

ad #6: you should check your locale-settings and verify that the command
getent passwd "yourfrenchusername"
succeeds and therefor samba can find your non-ascii-user before any further
testing with smbcacls/smbd.

To admit, I'm a little bit confused by comment #5. Could you please give a clear
example of how to reproduce this?

I still can't see any bug here.

Hi,

When i type getent :

getent passwd papaé
papaé:x:1591:513:Samba User:/home/papaé:/bin/bash

I can connect with this user from windows xp samba found this user .

On the log when samba search on ldap it found this user .

But i see :

  local_sid_to_uid: papaé found in passdb but getpwnam() return NULL!
[2004/11/25 20:04:27, 10] passdb/lookup_sid.c:sid_to_uid(392)
  sid_to_uid: local lookup failed

I think the fonction local_sid_to_uid can't find this user .

Are you shure you can add acl with user who have non ascii char name ?


If i add acl with user who his  name is c it make on the log:

ocal_uid_to_sid:  uid (1585) -> SID
S-1-5-21-1688021309-183578045-1594628879-1069 (c).
[2004/11/25 18:27:32, 10] passdb/lookup_sid.c:uid_to_sid(323)
  uid_to_sid: local 1585 -> S-1-5-21-1688021309-183578045-1594628879-1069


Are you shure  getpwnam() when the user have non ascii char work you don't
convert on utf8 the name of user?

I just install the samba 3.09 it make the same error .

When you make getent passwd "yourGermanusername" you have the non ascii char on
utf8 or on iso  because when me i have on utf8.

I can give you two log one when the user is c and the second when the user is papaé


passdb/passdb.c
Convert a SID to uid - locally work with user non ascii char?

But the strange is the group with non ascii char work fine.

The fonction SID to gid work.


Thanks

Hi,

I just see the problem.

I modify unix charset = ISO8859-1 to unix charset = UTF-8 :

    dos charset = cp850
    unix charset = UTF-8
    display charset = UTF-8

The acls work but i can't use this charset because :
 smbclient //localhost/u2
Password: 
Domain=[DOMNT] OS=[Unix] Server=[Samba 3.0.9]
smb: \> ls
  .                                   D        0  Fri Nov 26 13:09:21 2004
  ..                                  D        0  Fri Nov 26 13:12:53 2004
  test2                                        0  Fri Nov 26 13:07:30 2004
  e_                                           0  Fri Nov 26 13:09:21 2004

		34980 blocks of size 524288. 34179 blocks available

The file with accent is modify you can't see the accent you just see e_ (_
normaly is é)

When i use net prc vampire  i must use with utf-8 because ldap use utf-8 .

What is your charset?

Why i can add acl with  group who have non ascii char?

I make getent group (group with non ascii char) :
Invit\C3\A9s du domaine:x:1591:
titi\C3\A9:x:1607:b,c,d,e,é,éé,f,ié,Invité,IUSR_NT2,misc,papaé,testé

Thanks

HI,

I must make search the user on utf8 if i use the char non ascii it can't found .

[root@test share_acl]# getent passwd  papaé
papaé:x:1591:513:Samba User:/home/papaé:/bin/bash

Very strange if i use the good unix charset = ISO8859-1 for see the file name
with non ascii char i can add acl group but no acl user .

I use ldap on utf8.

Do you use ldap if yes your ldap is on utf8 or iso...?

Because i make a long test but i don't found a result.
thanks

Paul, I just can repeat myself: please check your locale-settings
type:

   locale

and see if your system is using UTF-8 as well. This might be the source of your
non-samba related problems. Otherwise consult your system-documentation to see
how to change your locale settings. 

In my tests I just use samba defaults (unix charset = UTF-8, display charset =
locale) and I have all my locale-settings using UTF-8. 

Sorry, I can't reproduce any of the errors you are seeing, not as a
domain-member with winbind and not on a domain-controller using ldapsam. And not
with either users or groups containing german umlauts or french accents. Believe
me, I double-checked. There is no bug in smbcacls.