-- our setup is as follows:

"hide unreadable" is turned on.
we have a share "home", which goes to /home.
There are several hundred directories, with all but four belonging to individual
users, and the access masks are 0700.
We don't use ACL's, just go along with the unix permissions.


-- the problem is:
If you try to list this directory smbd is very busy and takes a long time to
check the visible files.


-- analysis
If you go to a subdirectory, and put a symlink there, which goes back to /home,
directory listing is fast as usual.

strace()ing smbd shows that smbd reads (and locks) smbpasswd and group_mapping
*for each entry*.

reading the source I see that for each entry (dummy) acls are created (one for
the parent directory, and one for the entry); and that creation takes some time,
I believe.


For our setup I changed the function user_can_read_file:

smbd/dir.c
@@-714,6 +714,9 @@
     if (!fsp)
              return FALSE;

+    close_file(fsp, True);
+    return access(name, R_OK);
+
     /* Get NT ACL -allocated in main loop talloc context. No free needed here. */
     sd_size = SMB_VFS_FGET_NT_ACL(fsp, fsp->fd,

and user_can_read_file got the same, except for the W_OK instead of R_OK.


-- reproduction recipe
generate some hundred users, give them directories with mask 0700, and get a
directory listing.


-- conclusion/solution
1) maybe the smbpasswd file could be cached in some kind of hash, so that it
needn't be parsed for each entry.
2) maybe an "empty" acl can be prepared, where just (at known positions) the
SID's are changed before being used, instead of building one from the start up.
3) how about a compile option to disable acl support (I believe 2.2 had this),
which would speed up such operations?
4) any other ideas?


Thank you very much!