Windows ACL permissions not working properly

[beargfr]

I have an issue with my QNAP 451+:

* It is joined to my Windows domain (it is NOT set as a domain controller of any type).

* Privilege/Shared Folders/Advanced Permissions:: Enable Advanced Permissions and Enable Windows ACL are both set on (enabled).

* I have a shared folder with (at least) 3 levels of subfolders under it.

* On the QNAP, I have permitted a specific Windows AD group full access to the top level of the shared folder via the QNAP control panel.

* Using Windows Explorer/Properties/Security, I have permitted the same Windows AD group full access to all of the folder levels underneath this folder.

* I've used Windows Explorer/Properties/Security/Advanced/Effective Access to test whether a user in this AD group has access, and the tool reports that the user has full access to all the folders as expected.

Yet when a user in this AD group attempts to create a new file in one of these subfolders, permission is denied.
Therefore, I believe something is not working correctly.

[AndrewPound]

Hi, Best I can do is add to your plight, Setting windows permisisons on QNAP's just does not work, no ifs no buts, from the shared folder permission of a folder, remove domain users, change owner to user, and tick apply and replace all exisitng permisisons, for this folder, files and sub folders and click on apply, a little later all compolete, check first sub folder and none of the permisisons you just set have been done, I honestly believe QNAP do notuinderstand Wwindows permisisons so dont bother to make them work!, I have tried to discuss this with them but they will not accept it does not work, even in one off instances, I am trying to find a way of making the chown -r work on domain permission, will let you know if I get anywhere! good luck

[planes_trains_autos]

Chiming in with Andrew. After every QNAP update my box goes on the fritz with bizarre permissions, even placing inactive domain users with RW permissions on shares. Totally screwed up. I am very frustrated with QNAP support and am currently in the process of replacing it with a Windows file share server. The hours I have spent changing permissions and re-applying security is ridiculous. I have had this unit for a few years as a "cold" storage device for files, with a local logon, but needed to move my user shares due to space issues on my VMWare environment. Once I moved them over several months ago it has been nothing but a headache. I think the QNAPs are fine for "non-production" type environments but be very careful when using as a backup or file share for "hot" data in a production Windows environment. Also if you are using QNAP for your backups: https://www.crn.com.au/news/qnap-keeps- ... ata-468923.

[bugyou3]

This feature has never ever worked, AFAICT.

[schumaku]

CAlso if you are using QNAP for your backups: https://www.crn.com.au/news/qnap-keeps- ... ata-468923.

Issue exists on degraded RAID5/6 only. Fixed in QTS 4.3.3.0262 ff. available for some days.

[keson]

Unfortunately I have to confirm, this is an issue sfor us too..
I have setup a new environment - Win src 2012 R2, AD, DNS, TS.
New NAS purchased QNAP TS-451+. Disks populated, volumes created. Domain joined. ACL and advanced permissions enabled.

User data folders moved to NAS through GPO, all nicely worked.

All worked until I created a shared folder and I wanted to set AD groups/users to access it based on permissions - RW or RO.
This simply does not work. Even when I check the Shared folder properties, I can see that the permissions are set correctly - AD groups and users have the correct sign/colour (green for RW, orange for RO). However it does not play any role, NOBODY can upload/create any file/folder.

I have tested everything possible. Setting all the permissions either from Windows or from QNAP web GUI. No effect, still does not work.

FW is latest as of now 4.3.3.0299 build 20170901


I would say this can be considered as a show stopper foe anyone who wants to integrate the NAS to their AD as this I consider as a basic feature - I need to be able to set permissions based on the groups memberships. And if the feature is supposed to work (the system claims it does honour the groups and user permissions), then I do not understand, why it simply does not work?

[twil21]

Same problem here. Qnap TS-212P, FW 4.3.3.0299. I have joined the domain.

Settings with groups/users from AD work only for some of them. Some users from the same AD group can upload, some can't. That's bizarre.

[twil21]

My guess is that the first user from the group has RW access, the rest of users from the group have only RO... very odd!

[twil21]

I submitted a ticket to QNAP, there answer was:

"Hello,
with Windows ACL set up, you need to first grant the permissions on the share folder directly on NAS. This can be done in Control panel > Shared folders. For subfolders, the permissions will be taken from the ACL directly.
So in your case, please make sure that the domain users/groups have access to the parent share folder (for example Public, Multimedia or Download from the default ones). Does it still not work?
Thanks"

And they were right. I set the share permissions correctly, and all went well.

Best regards to all.

[chrwood]

I'll chime in as well. So the permissions for me works as above but when it comes to sub folders my users aren't able to move from one folder to another. It is soo close to working but this function is just killing me.

[TS435U]

We also noticed strange problem with ACLs: we copied users folders to QNAP CIFS share with preserving ntfs ACLs (domain admin was owner of all files/dirs on the source vol), after that we noticed that for some reason on QNAP share domain admin account was replaced with QNAP embedded admin user in ACL on all files/dirs. May be QNAP support is following this forum and could advise us why it happened?

Seems like indeed QNAP has big problem with Windows ACL permissions. Would be nice to see their comments here.

Model name TS-453U-RP
Firmware version 4.3.3.0404 Build 20171213

[schumaku]

May be QNAP support is following this forum and could advise us why it happened?

As the title says, this is a community forum. For QNAP Customer Service support -> https://helpdesk.qnap.com/

If you expect a 100% NTFS complaint behaviour, retaining the NTFS ownership and ACL, thee is no other way but run NTFS volumes on iSCSI LUNs.

[TS435U]

...If you expect a 100% NTFS complaint behaviour, retaining the NTFS ownership and ACL, thee is no other way but run NTFS volumes on iSCSI LUNs.

Thanks a lot for the advise! I will try to switch to iSCSI LUNs instead of using of CIFS shares, as it looks like this is the only solution we could try now, because QNAP Help Desk is useless:

I opened ticket #AUS-385-31575 on Jan 17th, and since that the only meaningful update I got from QNAP support on Feb 18th was to remove embedded admin user from the CIFS share access list. So I removed NAS admin user from the Shared Folder Permission list and left there just Domain Administrators group, but again if we copy any folder to QNAP CIFS share it replaces Domain Administrators with its embedded admin account, and it's really odd. Because of this we can't set NAS in production since January! And we are waiting for any advise from QNAP during a month.
Now we're really frustrated that we choose QNAP TS-453 as file storage for corporate data.

[beargfr]

If you expect a 100% NTFS complaint behaviour, retaining the NTFS ownership and ACL, thee is no other way but run NTFS volumes on iSCSI LUNs.

This might work but it has it's own issues. If you need read/write access across multiple Windows systems with both read and write integrity, then you have to share it out to the rest of the network from Windows. Having multiple systems accessing the same iSCSI LUN directly with all having read/write access isn't supported. Updates/changes are not/may not be visible to other systems and you're exposed to corruption caused by write "collisions" - there's no locking protection. If only one Windows system has the iSCSI LUN and shares it out to the rest of the network, then access from elsewhere in the network is always "double dipped" through the owning system so there's a performance hit for that, and if the owning system is unavailable then the target is also, even though the NAS itself may be up and running just fine - unless you reconfigure "everything" to route through a different Windows system. It's a mess.

[schumaku]

This might work but it has it's own issues. If you need read/write access across multiple Windows systems with both read and write integrity, then you have to share it out to the rest of the network from Windows.

Yes, of course - an iSCSI LUN is just block storage. Not much a NAS can do on top if it. An what can be done is in place.

Having multiple systems accessing the same iSCSI LUN directly with all having read/write access isn't supported. Updates/changes are not/may not be visible to other systems and you're exposed to corruption caused by write "collisions" - there's no locking protection.

Approach is systematically wrong. iSCSI LUN can be accessed concurrently - this requires the OS you access is cluster storage aware, does handle the block locking et all. Not a NAS problem, much more a problem with a wrong implementation.

If only one Windows system has the iSCSI LUN and shares it out to the rest of the network, then access from elsewhere in the network is always "double dipped" through the owning system so there's a performance hit for that, and if the owning system is unavailable then the target is also, even though the NAS itself may be up and running just fine - unless you reconfigure "everything" to route through a different Windows system. It's a mess.

Undoubted, multiple systems are involved, typically single ones. But then, there is nothing that holds you back from set-up a Windows Server cluster - which can of course again deal with the iSCSI over multiple channels and access vectors. At the end of the day, millions of users are accessing and working on shared folder held on non-Windows systems - being large scale storage systems of the very big vendors, or other "smaller" storage, most operating SAMBA.