The "DOMAIN\JSmith" user should not be getting "Access Denied" upon trying access the share, but should be getting "Access Denied" when trying to create or modify files hosted there. Can you clarify what you mean by "John Smith gets an Access Denied message when trying to access this share." with my prior statement in mind?
In general, "Share Permissions" should always be set to "Everyone / Full Control". They're a brain-damaged misfeature from back in the days when people might share out folders hosted on non-NTFS volumes. (Anybody wanna argue about it? Heh heh...)
"Share Permissions" are enforced by the "Server" service. If users are able to access files via some other method (a "Share" higher up in the filesystem with different "Share Permissions", files exported via IIS with some other protocol, etc) then the "Share Permissions" won't apply. Specify your permissions in the NTFS permissions, and then no matter how users access the files the NTFS driver will enforce the desired permissions.
For academic purposes, I'll explain how "Share Permissions" work (but I'd still encourage you to always set them to "Everyone / Full Control"): The "Server" service (which handles exporting "Shared" folders via the SMB protocol) verifies that the underlying NTFS allows the user's attempted access (read, write, etc) and then checks the user's attempted access against the "Share Permissions". If either permission doesn't allow the desired access then the access attempt fails. Setting "DOMAIN\JSmith" with "Full Control" permission at the "Share Permissions" doesn't change the underying NTFS permission. At the filesystem level, "DOMAIN\JSmith", a member of the "DOMAIN\Domain Users" group, has Read, Execute, and List Folder Contents permission by way of the default nesting of "DOMAIN\Domain Users" into the "FILESERVER\Users" group when you joined the domain.
You shouldn't ever name individual users in permissions except for folders that are specifically created for that user only, such as roaming user profile folders or home directories. Since this share is named "JSmith" I'm going to guess it's a home directory. Add "DOMAIN\JSmith" with either "Modify" or "Full Control" (depending on whether you want JSmith to be able to modify the permissions on the folder and subfolders or not-- "Full Control" will give him that right) to the folder's ACL and you should be good to go.
If a shared folder is for some other purpose (i.e. for a "job role" or sharing between users) the Right Way(tm) to apply permission is to create a group that describes the role associated with the access (like, say, "Purchasing Department"), grant permission to the NTFS folder for the resource to the group (like, say, "Modify"), and place the appropriate users into that group.
When a job role changes or turnover occurs you need only put the "new person" into the proper groups and their access to resources is assured. If you'd named individual users in permissions then the only way to insure access for a new user would be to visit each resource and add new permissions (possibly removing the old permission if a job role changed). If you don't keep good documentation of where you applied various permissions to individual users then you'll never be able to create a new user with the "same rights" as an existing user w/o a massive investigation effort on all your resources.
Even if a group is going to have a single member, create a group anyway. You'll thank yourself later when you have to assign someone else to the group.
An Access Control List (ACL) is the list of Access Control Entries (ACEs) applied to a resource. The ACL is what you're seeing on both the "Security" tab of a Properties sheet, and in the "Advanced" dialog. Each line of the ACL is an ACE. (I thought I'd bring "ACE" into it, just in case you see it in documentation somewhere and wonder what it means...)
You're seeing the same thing in the "Security" tab and in the "Advanced" dialog, just presented differently (with more detail in the "Advanced" dialog).
I'm having trouble coming up w/ why you might be seeing an "Access Denied" upon accessing the share as you describe. With JSmith logged-on to his client computer with his domain account, and the FILESERVER computer joined to the domain, you should not be getting an "Access Denied". Are you certain JSmith is logged-on with his domain account on the client computer?