ReadyNAS DUO v2 (arm 5.3.5) Windows and UNIX File Permission

[tcapel]

This is a long posting to document what I have tried and TEMPORARY success.
However the fix I found is not permanent so it should be viewed as input to a final solution. I am not a UNIX or samba expert, so others may see a better solution.

My target configuration is to use the ReadyNAS to host shares with folder and file read/write/create/delete (full control) allowed from Windows (XP - Win7) machines who are members of a specific group (with any other machines denied such).

Firmware 5.3.5 (for arm) introduced additional options on the Share admin GUI to, for example, select Folder Create Group Rights, etc. (Under Protocol-specific Settings). I suspect that further firmware updates may be required by Netgear to solve my problem. Non-arm ReadyNAS devices are completely different, so this discussion is unique to the arm firmware.

So, initially I set up Share (network) access as follows:

I created Names and passwords for each Windows machine I want to access the Share using the ReadyNAS admin GUI (Security tab). I made these members of Group "users". On each Windows machine I used Control Panel|Credential Manager to add Windows Credentials for the ReadyNAS and entered the corresponding password.

I created a Share on the ReadyNAS using the Share admin GUI; under Share Access, I uncheck Read/Write "everyone" and then checked Read/Write for each of the Windows machines. This will force each Windows machine to log into the ReadyNAS, and deny access to everyone else (I hope!).

At this point I should be able to see this Share from the Windows machines.

Next I set up the file permissions for the share.

At this point I am entering new ground, and some of the things I am doing may be wrong. But bear with me, for a SHORT TIME I was able to get it to work as I had expected.

I now go to the "Protocol-specific Settings" on the Shares admin GUI. I keep Hide This Share, Enable Recycle Bin, an Enable Opportunistic Locking as unchecked to keep it simple. I check Automatic Permissions and leave Restrict ACL Changes unchecked. (I am using some of the documentation available for x86 ReadyNAS machines to understand what these are about).

I set Folder Creation Group Rights and File Creation Group Rights as "Read/Write" since I want any members of my "users" group to have these rights. I set Folder Creation and File Creation Everyone Rights to "Disabled" to deny these rights to everyone else. This may be redundant since I have not allowed everyone access to this share, but I like to be safe.

At this point I would have thought this would work. But it does not. New folders and files created by one Windows machine have the UNIX permission bits on the ReadyNAS set to dissallow group write access. So non-owners cannot write or delete these files, despite the expectation that providing Read/Write group rights would have allowed this. (This is confirmed using the UNIX ls -l command at a ReadyNAS prompt, see below.)

This is actually more complicated, since it is not only the UNIX permission bits which are at play. Samba (the software being used by ReadyNAS to provide the shares) is also emulating addition file access controls to emulate the shared filesystems expected by Windows machines (ACLs and acl_xattr).

At this point we dig deeper.

I use SSH on the ReadyNAS to allow me to log in as root (instructions for this are elsewhere on the forum). I used putty.exe on a Windows machine to access ReadyNAS (port 22). Login as root with admin password (which you might have changed!). The login response asking for a password has become slow on my ReadyNAS, you may need to be patient during log in (not sure why this is happening).

I used SSH terminal session from putty.exe to execute "smbstatus" at the ReadyNAS prompt. If a Windows machine is displaying the share, the Windows machine is shown in this list. This can be used to confirm that samba is recognizing the Windows machine (automatically logged in by Windows when accessing the share).

To see the UNIX permissions on the shares, I used SSH to "cd" to the root of the ReadyNAS filestore ("cd /"), list the root files ("ls"), locate the name of the share in this listing and "cd" to it. I then list the UNIX permissions (and owner and group) using "ls -l".

The problem I found was that new files and folders are created with r/w only for the owner not the group even though I set Folder and Creation Rights in the GUI to allow Group r/w. While it was possible to use the UNIX command chmod to change this to fix the issue; this is not a long term solution since chmod is only available via a root SSH login. I want Windows machines creating folders or files to create them automatically with group r/w. Also there is a concern that chmod only changes the UNIX permissions and it is not clear this will be replicated into the samba emulated Windows permissions (which I am not seeing with the ls -l command) (although there is mention that samba does try to align these permissions automatically - again, I am no expert on this).

Now the obvious thing to check is the Shares.conf file (in /etc/frontview/samba directory) for samba to see if the ReadyNAS admin Share GUI is setting the options correctly. Easiest to use the samba "testparm" command (which "tests" this config file and prints what samba sees). Entering this command and looking at the section related to the share (on the second page of the output), it is confirmed that the force create mode, force directory mode and the corresponding masks are changed by the GUI in the expected way.

Now it turns out a similar issue has been reported on Linux postings, see:
At http://lists.samba.org/archive/samba/2010-August/157630.html

I then used an editor on the ReadyNAS ("vi" seems to work) to edit the Shares.conf file to add the suggested force security mode and force directory security mode to the samba config file.

This seems to work. New files and Directories created by a Windows machine have the group r/w UNIX permissions set as expected now.

Now, the Windows permissions.

Going to a Windows machine I select a folder in the Share and open its Properties | Security page. At this point I am looking at a mix of UNIX permissions and the Windows permissions (both provided by samba). This is a means to check whether I have things set correctly. I want to have Full control only allowed for my Unix User \users group. If I see nobody nogroup with "Full control" I know I do not have it right! (This can happen if you use the "Reset Permissions" button under "Files and Folders" on the Share admin GUI page! Don't do that if you are trying to restrict access as I am wanting to do here!)

To fix problems, I think you need to use a Windows machine. Either use the Windows machine which is the owner of the folder, or use chown and chgrp at the SSH prompt (logged in as root) to change the owner and group (UNIX permissions) to the Windows machine you want to use.

You can then open the property page | Security page on this Windows machine and set the permissions (Full control to users).

After short testing this seemed to work as expected.

UNFORTUNATELY this is not permanent since when the Share admin GUI is run again and any permissions are changed using this GUI, the added force security mode entries are erased from the config file, so the problem returns for new files and folders. There is probably a way to make this permanent, but my preference would be to have a wider review of what I have done to confirm there is not a simpler way to fix this (or better to wait for a new firmware release - my preference!).

PS: Here are the smb.conf lines that seems to make it work (temporarily):

...	create mask = 0660
	force create mode = 0660
	force security mode = 0660
	directory mask = 0770
	force directory mode = 0770
	force directory security mode = 0770  ...

I believe there is an alternate fix to set the unix extension = no, but this may cause other issues, and I did not try that.

PPS: I have been working with legacy filesystem shares created with earlier firmware versions. The story above was created assuming a start from scratch, which I did not do. In general I was able to use the ReadyNAS terminal login as root to repair UNIX permissions to regain access to folders/files; and to use Windows machine (after making it the owner) to change Windows permissions. The "Reset Permissions" button on the Share admin GUI forces a rather drastic change (making all files fully r/w with ownership nobody/nogroup). It also puts nobody in the list of valid users (but this is erased if the Share users are changed using the GUI - which is likely a bug). There appear to be issues with firmware 5.3.5 in this area and we might hope for an update.

[GoggiP]

Hi ,

Have you tried to reset share permissions via the GUI and then setup the share permissions again. There is a checkbox that allows you to do this, ie. automactically set permissions. Also tick the checkbox above it regarding ACLs.

If this still fails try reinstalling the firmware update.

Are all devices on the same DNS address?

[tcapel]

Thanks for your comment.
Yes, in Duo V2 v 5.3.5 automatic share permissions were set as I describe and after this the new folders and files created subsequently were examined and found not to have the expected UNIX share permissions (r/w group); and members of group could indeed not erase/modify them as was intended.
The only option in V2 5.3.5 to set share permissions for existing files and folders is the button at the bottom: but that sets the UNIX permissions to everyone and owner to "nobody" which is not what is desired. I want the owners of the files to be whoever wrote them. But allow all members of owner group to r/w.
Not sure about "all devices on the same DNS address": all devices are on the same subnet, the devices are logging into the readynas ok, smbstatus at UNIX prompt is showing all devices properly logged-in with their correct unique names (so network name/passwords are working ok).

[tcapel]

I am unhappy to say that version 5.3.6 does not fix this problem.

[tcapel]

I continue to unhappily report that version 5.3.7 (arm) does not fix this problem. Permissions are not being automatically set for group write access. I continue to need to use chmod to fix new directories when they are created by one member so others can use it as well. This is a pain:
1) Log in as root
2) "cd" to root directory of shares you want to work this way
3) correct file permissions by entering:
chmod -R 770 *

[GoggiP]

A workaround or solution might be to choose option C from this aricle.

http://kb.netgear.com/app/answers/detai ... are-access

Here you can grant access per IP address rather than username.

[tcapel]

This article mentions Frontview and I was always unsure of whether such articles are applicable to arm devices (certainly modified instructions would be needed).

I would not want to switch from user to machine authentication - and "authenticating" to an IP address is not very secure.
For my application it is preferable to define users as members of a specific group (and individually authenticate users) and then apply access controls to the group. Netgear documentation appears to indicate this is possible.

I wonder if it would be possible for Netgear to try the fix I found on the Samba support site to see if this works? In my limited testing it appeared to fix the incorrectly set UNIX permissions.
I presume all that would be required is to find where the GUI sets the Samba config file and add the two "force security...." lines as suggested on the Samba support site. (I have not checked the Readynas code since 5.3.5 so I am not sure whether a newer Samba release is being used.)

[GoggiP]

Frontview is the frontview. It looks different in NV+v2 but it does or should do the same thing :). At this stage I would recommend an OS reinstall on the latest version of firmware 5.3.7. And setup your user permission as you require. This may sound weird but if you disable recycle bin can you see unix permissions on the windows machine for the share?

In 5.3.7 you can scroll to the bottom and it has a section called Files and Folders. Expand this. Here you can set the Folder owner and folder group. Enter the folder owner as nobody and enter the Folder group as group.

Yes please open a case if we need to add a feature request. I am fairly certain the latest firmware resolves all of your issues.

[GoggiP]

Sorry again by group I mean the group name of your created group.

[tcapel]

I believe you are correct, this issue appears to be resolved now.
Without reinstalling (and using arm version 5.3.7), and maybe after "refreshing" Protocol-specific-settings (not sure if this was required), the behaviour appears correct: the correct UNIX permissions (group access) are being set as expected for new files and folders. I will need to fix the old settings using the UNIX prompt (not a problem) but going forward it looks good. I did not need to reinstall the OS.
Thanks for this, much appreciated.