FreeNAS or WinRAR bug?

[AZweimiller]

Here's an email I sent to WinRAR support. Tell me what you guys think. If it's a FreeNAS bug or a misconfiguration with my CIFS then other apps should be affected. Can anyone else duplicate this?

Gentlemen,
I have found a bug in WinRAR that exists in 4.20 and the latest 5.0b5. I have a NAS powered by FreeNAS. I am connected from a Windows 7 Pro workstation over CIFS/SMB as a mapped drive letter.
1) Right click on an archive and from the context menu extract to folder.

2) The created directory does not inherit the NTFS permissions from it's parent. I cannot open or delete any folder created by WinRAR. See screenshot.

3) Here is a screenshot of the NTFS permissions tab. I have to SSH into the FreeNAS box and manually rm the directory.

Please understand that this is only a bug in WinRAR. 7zip and other applications can create directories on this mapped drive without issue. There is something with how WinRAR creates new directories that is causing the problem. I also tried Extract To... and gave a new folder name but the same thing happens.
Any resolution or workaround would be greatly appreciated!

 

[cyberjock]

If the issue doesn't present itself with 7zip or other applications then you need to talk to the winrar support guys. They may have a clue as to what goes on in the background when you try to extract a file. I remember that back in the day Winrar would always extract to your designated 'TEMP' directory and then move the contents to the destination. The drawback to that was you were extracting it to your C drive, then moving to your server. If you didn't have enough free space for the entire extracted data then it would fill the drive and error out. 7zip didn't do that as it extract straight to the destination folder. That is the primary reason why I left winrar and never went back. Now 7zip is second nature to me, supports every file format I have ever needed it to, and I wouldn't go back and buy a license of Winrar if my life depended on it.

 

[AZweimiller]

If the issue doesn't present itself with 7zip or other applications then you need to talk to the winrar support guys. They may have a clue as to what goes on in the background when you try to extract a file. I remember that back in the day Winrar would always extract to your designated 'TEMP' directory and then move the contents to the destination. The drawback to that was you were extracting it to your C drive, then moving to your server. If you didn't have enough free space for the entire extracted data then it would fill the drive and error out. 7zip didn't do that as it extract straight to the destination folder. That is the primary reason why I left winrar and never went back. Now 7zip is second nature to me, supports every file format I have ever needed it to, and I wouldn't go back and buy a license of Winrar if my life depended on it.

I am using 7zip now as a workaround. I narrowed the issue down a bit:

My NTFS permissions are set on the root of the filesystem and inherited downwards. I have three Active Directory groups, NAS_RO, NAS_RW, and NAS_FULL. My user account is a member of NAS_FULL and as you might suspect from the group name, NAS_FULL has full permission to the filesystem. Here are two scenarios that should work the same but do not:
1) Create folder on NAS, disable inheritance. Remove all ACL except for NAS_FULL -> Full Permissions.
2) Let WinRAR create a folder inside this folder. NTFS permissions are non-existent.
VS.
1) Create folder on NAS, disable inheritance. Remove all ACL except for AZweimiller -> Full Permissions.
2) Let WinRAR create a folder inside this folder. NTFS permissions are fine.
To summarize, when an AD group I am a member of has full permissions, WinRAR has trouble creating directories. When my AD user has full permissions directly, everything works as expected. It's very strange especially considering WinRAR is the only program I've found that has this issue.
I am using FreeNAS-8.3.1-RELEASE-p2-x64.

 

[AndrewH]

For anyone from the future like me, this bug still exists and is present with recent winrar and freeNAS instances.

I've tested extracting locally and copying to the NAS, permissions then look like this:

Code:

MainNas# getfacl A8XXL
# file: A8XXL
# owner: DOMAIN\fistname.lastname
# group: DOMAIN\domsupport
            owner@:r-------------:-------:deny
group:DOMAIN\domprojects:rwxpDdaARWc---:fd----I:allow
group:DOMAIN\domvalidation:r-x---a-R-c---:fd----I:allow
            owner@:-wxp--aARWcCos:-------:allow
            group@:rwxp--a-R-c--s:-------:allow
         everyone@:-wxp--a-R-c--s:-------:allow

From local copy:
MainNas# getfacl A8XXL2
# file: A8XXL2
# owner: DOMAIN\firstname.lastname
# group: DOMAIN\domsupport
group:DOMAIN\domprojects:rwxpDdaARWc---:fd----I:allow
            group@:rwxp-daARWc---:fd----I:allow
group:DOMAIN\domvalidation:r-x---a-R-c---:fd----I:allow

Winrar efectively writes a deny ACL for the owner. Any other user can access and use the folder, just not the owner.

 

[anodos]

What client? Are you using "unix" or "windows" permissions type? What FreeNAS version?

 

[AndrewH]

What client? Are you using "unix" or "windows" permissions type? What FreeNAS version?

Hi anodos,

we are currently running 10.1-U2, the share uses windows permissions and WinRAR 5.20 on Windows 10 1803. The NAS is also joined to a domain just like AZweimiller . I tested this on the same machine from the same user, if I extract straight to the network share I get the top permissions, the one with deny for the owner, if on the other had I extract locally, then after that copy to the NAS I get the bottom permissions.

We structured our NAS in such a way that the individual directories belong to the group first so that multiple people can work on the same files. It is pretty much the same setup as original poster.

I submited this bug to winrar as well and they claim to use the built in windows command to create the initial folder, they don't set any permissions, but it is still wierd considering winrar is the only extracter doing this. Have tested the same files with 7zip and din't get the permissions problem.