accessing share via netbios vs fqdn

Question

I have a weird situation where when I try accessing a share via fqdn although it doesn't explicitly say I have no access but rather gives unspecified error it doesn't work while when using netbios for the same I can access the share just fine. What's going on here? I wouldn't expect any difference in type of access. How can I get the exact cause of this issue? What's the difference when accessing shares via hostname vs fqdn.
Just for update I also noticed when the share is being accessed there is a log related showing ReadAttributes: Not Granted. This is even more puzzling as I confirmed the share permission is Read and NTFS Effective Permissions are Read/Execute. How do I get to the bottom of this?

Answer 1

since when setting up share permissions directly on my_folder I could see in Sharing tab the unc and description saying Shared.

I have no idea what you are doing. Are you setting up one share (shared_folder) or two (my_share) or three (my_folder)?

Now after modifying shared_folder share permission it works

This is what I tried to point out yesterday. You are describing things that you are doing, but not really providing any details. Forum users can only guess as to what permissions are set on any of these folders and any of the shares that you have.

In general share permissions act as a filter to the NTFS permissions, If a user has update access to D:\Data\Shared-folder but the share permissions to \servername\Shared-folder only have read access then the user will only have read access.

If you have D:\Data\Shared-folder\Sub-folder-1\Sub-sub-folder and wish to allow a user to access Sub-sub-folder through the share on shared-folder, then the user will need to at least have list access on Shared_folder and Sub-folder-1 in order to traverse the file system to get to Sub-sub-folder.

Answer 2

Accessing the share as requested via cmd gives "invalid password" which reminds me this is using smart card. Also we're talking Windows 10 client and Windows 2008R2 server so there was something about secure negotiate but not sure if this applies here.

Answer 3

I tested with smart card to other shares based on NAS and Server 2012 which works fine. I tested access with regular account and that works fine too. So only issue seems to be smart card and 2008 server. Monitoring the traffic I see Status_Access_Denied which I read can be the case If SMB signing is disabled at the client and enabled and required at the server. In this case I have have signing disabled on the server and RequireSecuritySignature set to False on the Windows 10 client.

Answer 4

I checked what are the share rights on the actual root share rather than the folder within the share. My understanding was that if I have a share like \servername\shared_folder I can set user to be able to only access \servername\shared_folder\some_folder\my_share by setting up sharing on the my_folder and granting necessary ntfs rights. It turns up however that I needed to adjust share permissions on \servername\shared_folder granting the user read right so she's able to access \servername\shared_folder\some_folder\my_share I don't understand why's that since when setting up share permissions directly on my_folder I could see in Sharing tab the unc and description saying Shared. Now after modifying shared_folder share permission it works but I don't understand why.

Answer 5

then the user will need to at least have list access on Shared_folder and Sub-folder-1 in order to traverse the file system

This is exactly what I was after here. So basically it would be same for my d:\shared_folder\some_folder so the user can get through to my_share. This makes sense now as I was thinking setting up share and ntfs permissions directly on my_share would suffice. Looks like the invalid password message was misleading in this case where the real problem was inability to traverse through the whole path. ... and I thought my understanding of share permissions is fairly good lol many thanks