Server 5.0.15 (El Capitan) Poor SMB3 Performance

Hey Robert, I have experienced a similar issue, but the other way around, AFP hangs for a long time while SMB is quite springy. Same configuration, latest El Cap with Server 5. Very odd.

My problem is that with SMB I am unable to open and then save files on the server, I keep getting the message that I don't have permission (even though I am using the same administrator password on the server, and the volume and files have the same administrator permissions). If I switch to AFP it works fine. But that leads to another problem where my volumes won't show up on my client computer with only AFP enabled, the only way to see those volumes is by choosing "Connect to Server" in the Go menu.

It's a conundrum here, I want the whole cake but I'm only able to get one slice at a time. It's driving me crazy! I'm very interested in seeing what people add to this thread...

Did you ever resolve you permissions issues here? I have something similar. The shares on my server work fine under AFP but the moment anyone uses SMB to edit a file on the share that file becomes their sole RW item. Groups goes to "No Access". This means that I am having to force our Mac users to use AFP and using a NAS for the Windows users who have there own shared folder.

Any points on getting SMB to respect the shared folder permissions would be greatly received. Oddly it seems to be only the POIX settings that are changed (the ACL one - a "manager,entgroup" one stays with RW setting).

With the help of Apple Enterprise Support I was able to completely resolve my issue yesterday. We did the following:

1) Update the DNS settings on the client to only look to the server IP address (instead of the router). This helps make sure that the connection is always stable, as opposed to asking the router who the client should get content from.

2) Create a folder inside the Volume (in this case multiple thunderbolt drives) that will act as the share point, as opposed to making the volume itself the share point. Apparently SMB has issues with sharing volume at the root level so making the folder the share point is the fix. Which for me is fine because the folder I created (same name as the volume) mounts just like a volume with all the content inside the same so the client doesn't know the difference.

3) Edit the permissions for each share point (new folder mentioned above) and added each user/group to the list, and choosing 'Full Cntrol' and then in the drop down list making sure that everything under 'write' is enabled. This is the most important step for being able to overwrite files using SMB, and it only works with this type of permission on a folder as a share point.

Hope this helps!

Thanks for your reply.

1. I will have a go with the DNS. All my computers point to the router which in turn points to the server.

2. Already sharing a folder inside a volume (on Thunderbolt).

3. To clarify: Do you mean that in Server.app under File Sharing you are adding everyone who needs access as "Read & write", as opposed to just adding the group they belong to? I.e Three users in workgroup. Add user1, user2 and user3 as R&W individually not as a group permission setting?

Thanks

Hey Frando, you can do users or groups, but I am only using users so I can't verify if groups works for sure. But note that it's not 'Read & Write' privileges that you are adding but 'Full Control.' Huge difference as the Read & Write does not give you complete write/delete permissions the same way that Full Control does. I don't fully understand the reason but I can verify that it works in my case. Don't forget to make sure that Write has a check next to it in the drop down list and not a minus, because you need full Write privileges.

Also note that if you don't see the option for "Full Control" privileges then you should add the user/group again in your ACL. I found that the users that were already there did not have the option until I added them again in the Server app (in the Storage tab).

You may need to restart the client machines just to make sure they aren't holding onto the old DNS/privileges.

Let me know if you have any luck.

Hey Robert I thought the same thing regarding permissions being correct but in my case I was mistaken. All of my users had Read & Write privileges but it was not enough. Had to add them again to my ACL (Storage>[Share Point]>Edit Privileges) and then change the privileges to 'Full Control' (drop down the list and check 'Write' which by default has only partial settings). After that I was able to overwrite files opened over the network. Not sure if this would help your situation but I hope it helps get you closer.

Hey Robert, I just had another thought. You might try turning off AFP completely for every share point, having only SMB enabled, and see if that gets thing flowing better. Enterprise tech told me yesterday that Apple defaults to looking for AFP first, then SMB, and if one volume mounts using one protocol then all the other volumes will default to only that protocol.

I was experiencing a very slow network until I changed all the services to match, but I also manually changed the DNS settings for each client to look only to the server. Seems to be flowing swiftly now, not sure which of the above was the culprit.

You're looking at permissions in the File Sharing pane. Go to the main server pane (top left) and then the Storage tab:

Then choose the share point and then edit the permissions. You may have to add the user again as the option for Full Control may not appear unless you add them fresh (which happens in my case). Looks like this:

However, if no one is complaining about being able to overwrite files (and with AFP they won't, it is only SMB that this is important for) then this probably isn't necessary.

I'm betting the farm that if every client machine has the DNS manually set to server IP, and you have every File Sharing folder set only to SMB, you will see a boost in performance. Keep me posted, I'm interested in hearing how it works out.

Maplevshoney thanks for sharing all your info. I thought I should add to this as well in case it helps.

We have been having sudden slow downs whilst using SMB and AFP. We have 70 or so AFP clients and 20 smb clients. All of a sudden the SMB clients would grind to an almost standstill . AFP clients would be OK for a while at least. This has been a rather testing time in a rather busy design studio. With lots of moaning from the clients and myself struggling to find the answer.

But I finally believe i have found the culprit and its actually a simple one, as a bit of detective work showed, whilst the migration from AFP to SMB seemed to be OK with ACLs etc propagated correctly.

The one thing that didn't change with the adoption of SMB is the names of the files everyone was working on.

So users were opening files create in AFP which contained illegal file characters.. (bad policy I know..) but after years of using forgiving AFP, users are now understanding the problems of naming incorrectly with the use of SMB. I am now running scripts to remove the illegal characters,which is annoying with linked files in indesign etc, but it will be better for the the long term adoption of SMB.