[Samba] slow directory access, convert_string_internal: Conversion error: Incomplete multibyte sequence

[Gaiseric Vandal]

I think the issue may be related to the broken trusts.        First of 
all only two people had specifically reported issues which meant for 
most people it was acceptable.   Then I noticed that some directories 
seemed slower than others.

If I ssh'd into the server and checked permissions, listing permissions 
on most directories was quick (under 2 second.)  On directories that 
allowed access to trusted domain members (e.g. "Research") listing 
permissions might take 30 seconds.     The unix uid numbers   10157 and 
10172  shd resolve to users from the trusted domain but can't.

Solaris ZFS file systems supports ACL's  similar to windows in the sense 
that not limited to a single user and single group.



# ls -lvd /Pool1/Department/Sales
drwxrwx---+ 13 jsmith      sales            48 Nov 29 18:58 
/Pool1/Department/Sales
      0:user:nobody:read_xattr/read_attributes/read_acl:allow
      1:user:root:read_xattr/read_attributes/read_acl:allow
2:group@:list_directory/read_data/add_file/write_data/add_subdirectory
/append_data/read_xattr/write_xattr/execute/delete_child
/read_attributes/write_attributes/delete/read_acl/write_acl
          /write_owner/synchronize:allow
3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
/append_data/read_xattr/write_xattr/execute/delete_child
/read_attributes/write_attributes/delete/read_acl/write_acl
          /write_owner/synchronize:allow

# ls -lvd  /DataPool1/Dept/Research/
drwxr-xr-x+  4 jsmith  research       5 Jun  6 15:05 
/Pool1/Department/Research
0:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
          /read_acl:allow
1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
/append_data/read_xattr/write_xattr/execute/delete_child
/read_attributes/write_attributes/delete/read_acl/write_acl
          /write_owner:file_inherit/dir_inherit:allow
2:group@:list_directory/read_data/read_xattr/execute/read_attributes
          /read_acl:file_inherit/dir_inherit:allow
3:group:group_leaders:list_directory/read_data/read_xattr/execute
/read_attributes/read_acl:file_inherit/dir_inherit:allow
4:user:10157:list_directory/read_data/read_xattr/execute/read_attributes
          /read_acl:file_inherit/dir_inherit/no_propagate:allow
      5:user:10162:list_directory/read_data/add_file/write_data
/add_subdirectory/append_data/read_xattr/write_xattr/execute
/delete_child/read_attributes/write_attributes/delete/read_acl
          :file_inherit/dir_inherit/no_propagate:allow
      6:group:15001:list_directory/read_data/read_xattr/execute
/read_attributes/read_acl:file_inherit/dir_inherit:allow




Clearing the invalid users seems to help.     Although even problem 
directories, access on a 2nd try with in a minute would go faster.



Thanks for the help.





On 11/30/16 11:50, Jeremy Allison wrote:
> On Tue, Nov 29, 2016 at 08:28:45PM -0500, Gaiseric Vandal wrote:
>> There are definitely some files with some weird names-   in an ssh session they don't even have regular characters.
>>
>> e.g
>> -rw-rw----   1 xxx   xxx     114985112 Oct 31 14:39 ▒^t
>>
>>
>> Not sure if that is related to problems though.
> Well that's the source of your debug messages. I'd fix
> those if I were you.