Slow fileshare browsing (tree opening, ...)

Hello to all,
I have latest (now I see it is 7.5 1804 beta ) NethServer in production and AD works pretty good. There are two main groups DomainAdmins and DomainUsers that access main share that has also ntfs permissions involved. Share access is r/w for all but later on ntfs permissions manage real access.
But I noticed significant response/speed difference when browsing folders (just browsing, not file transfer) as an DomainUser or as an DomainAdmin . When logged as DomaiUser file tree opens with certain annoying delay (1-3 sec) (and further browsing also) , but as soon as User becomes DomainAdmin member browsing and tree opening speeds up to a light speed.
image


image

linux permissions to this share
drwxrws—+ 6 admin@sxxl.local domain users@sxxl.local 4096 May 2 06:47

So everything works logically as it should: ntfs permissions work correct, there is no network bottleneck because file transfer happens at 80-90MBs .Does somebody have a clue what could cause this ?

… one more thing : Security groups are listed as users but not as group (user icon instead of group one):
image
Does it maybe mean that permissions are misinterpreted ?

Thank you very much in advance

Best Regards
Tonci Stipicevic

I could not reproduce the issue. It takes about 3 seconds to list the domain members when I am logged in with a non-domain user but there’s no difference between domain admins or domain users.

Which Windows version do you use?
Does it occur on another Windows machine too?
Is there a difference in using IP or hostname when accessing the share?
Do you use NFS or IPS? It may slow down samba connections.
You may try to disable the explorer preview (just an idea…)

Groups look normal on my side (Windows 10):

grafik

Hello Markus
I apologize I was not clear enough … it is about browsing and opening directory tree while browsing mapped fileshare in windows explorer … So DomainAdmin member does this in real time , but DomainUsers does this very slow and always “sandwatch” appears (for 1-3 seconds) . Running “Properties” of some folder enumarates folders and files much slower.
The same effect shows up either from the virtual win7 machine on the same host, or from the physical win10 machine on the lan, or either one lan member.
You’re right … domain members are listed slowly but this does not matter in terms of using an fileshare.
If you are referencing to NFS server share there is not any. IPS is not involved … Nethserver is not used as an gateway
So I just have to put DomainUser in DomaiAdmins group through RSAT tools and after that this everything runs as fast as light :slight_smile:

Thank you once more
BR Tonci

1 Like

I’ve found the cause !!!
This has been opened long time ago and it exactly points to my problem https://lists.samba.org/archive/samba/2015-April/190969.html


Hmm looks like earlier return for users with root permission,
so admin users would not go through SMB_VFS_GET_NT_ACL(),
which takes more time on permission checking.[1]

Non-admin users would go through SMB_VFS_GET_NT_ACL(),
and finally would reach getegid() and geteuid().[2]


The users that belongs to DomainAdmins groups are privileged regarding performance only because of this line in “resultant” smb.conf file -> admin users = “@domain admins” !!! So every share I made has this line and if I want to enable other users to use the share as fast as possible , other users of groups have to be added to this line i.e. -> admin users = “@domain admins” @other-group !!! Then those users belonging to this other-group have root-level access to the files in the share avoiding any ntfs permissions etc. I’m not happy with this solution but it is acceptable because the whole other-group can have rw rights anyway. … but there is another big BUT !!! … every time share configuration is being changed through gui , those custom entries are deleted. So , we have to use templates in order to preserve such customization … or maybe this value could be included in gui ? :slight_smile:
Obviously , access policy has to be moved up to share level … using ntfs permissions still has not been optimized so far .

Is it possible to define custom templates and assign them to different “types” of shares ? i.e.

So in this scenario , I will not be dealing with ntfs permissions in one “big” share , but I will create more different shares for different users/purpouses. In that case I will always have to extend the "admin users = " line in order to add users that will in realtime with this share

So the question wolud be how I could achieve this ? … through templates … where to tell this kind of shhare will use this template ?

Or is there some other way to , maybe, speed-up ntfs permissions usage ?

Thank you very much in advance
and
BR
Tonci

Yes, it is possible with shared folder profiles:

http://docs.nethserver.org/projects/nethserver-devel/en/v7/nethserver-samba.html#shared-folder-profile

In /etc/e-smith/templates/etc/samba/smb.conf/ibay-default/30share_adm you’ll find the "admin users = " entry.

I can’t recommend to make any user to an admin user in samba but I don’t have another solution now.

Would it be possible for you to change from ntfs perms to share rights/ACLs manageable via Nethserver web UI?

1 Like

Thanks Markus … ACLs would be very good option too If I will be able to achieve good performance.
Ok I know for those templates but need this scenario :

share1 -> admin users = @group1
share2 -> admin users = @group2
…

So If I change admin users in this template all my shares will be affected but this is not initially planned

Today I wll give ACLs a try and report back a.s.a.p. :slight_smile:

till then
BR
Tonci

1 Like

It works per share too. You may create a new profile by copying the files from /etc/e-smith/templates/etc/samba/smb.conf/ibay-default to ibay-group1 and ibay-group2 and make the appropriate changes.

Then you can map a share to a profile with:

db accounts setprop share1 SmbProfileType group1

But using ACLs is the better way as regards security.

1 Like

Yes! TNX!!! it works and now I can preserve admin users property .
Unfortunately , performancewise ACLs have the same effect as the ntfs permissions :frowning:

accessing shares with ACLs or ntfs perms , it takes to save acad dwg file in 70 secs , but with admin user property it takes about 2-3 secs

No matter the share contains 1,5T data (cca 1000000 files, 90000 dirs, etc …) or 100files / 20 dirs

I don’t think it is that risky to make any user “admin user” of that share because that “any user” would access this share with full-ntfs-permissions anyway … but , of course I know what you mean , there is not too much space to manage sophisticated security this way :frowning:

All in all you saved my reputation :slight_smile: because those acad designers do not care about microsoft, do not care about linux, but they do know and notice waiting for file to be saved in 70 secs instead of 2-3 sec :slight_smile:

So this is one big step ahead , but we must not step out of this “limitations”.

Those ACL seem to be something like share-permissions unlike ntfs-permissions ?

Thanks
BR

Tonci

The ACLs are on file system level too.
I am happy that it works.

Hmm … I think we have problem here … I installed ubuntu VM as file server nearby and joined neth-AD-domain successfully . Using winbind in ubuntu solved my problem at all ! There is no directory tree browsing delay any more, there is no slow document saving any more … everything moves much quicker (like in nethserver by “admin users”) … Ntfs permissions are involved too, of course … This scenario completely fulfill my needs/requests … This is what clients want to see/feel
Where are we now ? Is maybe the word “winbind” the key one ?
BR
Tonci

I still could not reproduce your error with domain users.

Please check if

  • Nethserver does DHCP and DNS for your clients.
  • your clients are using Nethserver as DHCP and DNS server.
  • the client is correctly joined to the Nethserver samba domain.
  • it works with a simple guest share without ACLs.

nethserver is dhcp and dns for domain joined client. Although I think dhcp is not that important for this matter. every join was successful . I’m not sure I understood your last point ? … No matter ACLs or ntfs permissions are included, If user belongs to “admin users” than we have realtime performance. When he is not , then ntfs permissions are respected and everything slows down. So “admin users” do not respect acls and ntfs permissons at all . You can deny everything in ntfs perms, but “admin user” can do whatever hi wants …

I meant if it does affect shares with read/write guest access too. But as you wrote it seems to have nothing to do with share rights/ACLs.