Migrate to DFS from UNC file shares? Complications..
-
@ntoxicator said:
As this would not be a local disk on the Windows server and it would be considered a network location and windows server would have a hard time applying file/folder permissions for users/groups?
Huh? It would be a local disk. The AD system has nothing to do with "applying" permissions.
-
@scottalanmiller said:
AD: Authentication
FS ACLs: Permissions
SMB: Share Permissions on the networkYou want something with all three.
-
@scottalanmiller said:
@ntoxicator said:
As this would not be a local disk on the Windows server and it would be considered a network location and windows server would have a hard time applying file/folder permissions for users/groups?
Huh? It would be a local disk. The AD system has nothing to do with "applying" permissions.
I understand.
In reference to AD, I was meaning the windows server in itself. This would be the file folder share permissions and the NTFS read/write permissions. Now, these are typically applied to local disks on the actual server.
The NAS setup with SMB share would be new to me. But, yes I understand it
I would need NAS with AD integration, so I can streamline and secure the SMB share over the network (Set of users who can access this share).
Then I would need FS (file system) permissions on the SMB share (on the NAS). Which would also rely on AD user/group
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
Yes -- I read some information awhile back on Spiceworks.
-
For DFS, your GPO looks like this. The same as with a basic SMB share. jsut you use the namespace instead of server. Nothing new or special.
-
@ntoxicator said:
@scottalanmiller said:
@ntoxicator said:
As this would not be a local disk on the Windows server and it would be considered a network location and windows server would have a hard time applying file/folder permissions for users/groups?
Huh? It would be a local disk. The AD system has nothing to do with "applying" permissions.
I understand.
In reference to AD, I was meaning the windows server in itself. This would be the file folder share permissions and the NTFS read/write permissions. Now, these are typically applied to local disks on the actual server.
The NAS setup with SMB share would be new to me. But, yes I understand it
I would need NAS with AD integration, so I can streamline and secure the SMB share over the network (Set of users who can access this share).
Then I would need FS (file system) permissions on the SMB share (on the NAS). Which would also rely on AD user/group
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
Yes -- I read some information awhile back on Spiceworks.
You got it all correct there!
-
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
-
@scottalanmiller said:
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
Ok --
"On the windows server". I meant if I create the SMB shares on the actual Windows Server VM on those disks.
now, if I create SMB shares on a NAS / network device.. That would be different and ofcourse this is not 'on the windows server'.
It has all come together for me.
-
@scottalanmiller said:
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
well, his issue of needing to be concerned if NTFS permissions was supported or not wouldn't be there if this was a Windows Server instead of a NAS appliance.
-
@Dashrender said:
well, his issue of needing to be concerned if NTFS permissions was supported or not wouldn't be there if this was a Windows Server instead of a NAS appliance.
-Correct
-
@ntoxicator said:
@scottalanmiller said:
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
Ok --
"On the windows server". I meant if I create the SMB shares on the actual Windows Server VM on those disks.
The fact that the Windows Sever is a VM also doesn't matter. As long as Windows sees and considers the disks local to itself, SMB and NTFS file permissions work the same as any physically install server on bare metal. You just don't need to worry about the fact that it's a VM. i.e. if you are mounting vis iSCSI or Fiberchannel or DAS using SAS through an external adapter - none of these things matter. Windows considers all of these local, and work as normally expected.
-
@Dashrender said:
@scottalanmiller said:
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
well, his issue of needing to be concerned if NTFS permissions was supported or not wouldn't be there if this was a Windows Server instead of a NAS appliance.
None of that was covered, though. No amount of Windows, AD or SMB covers that. Only NTFS ACLs provide that. You can do with with actual NTFS or you can do it with Linux VFS and an NTFS ACL layer. Either way, works the same. But the only device that can give you ACLs is the device providing SMB. So the Synology NAS in the example.
-
@scottalanmiller
None of that was covered, though. No amount of Windows, AD or SMB covers that. Only NTFS ACLs provide that. You can do with with actual NTFS or you can do it with Linux VFS and an NTFS ACL layer. Either way, works the same. But the only device that can give you ACLs is the device providing SMB. So the Synology NAS in the example.Understood! Thank you sir.
