OS6.1.4 and reset pemissions: strange behavior or bug?

[superceu]

I have a share configured this way:
Folder owner: htc1
Folder group: admin
Grant rename and delete privileges to non-owner of the file/folder: no
Folder owner permissions: read/write
Folder group permissions: read/write
No other permissions are granted.

This is the ACL configuration (and it's right):

root@readynas:~# getfacl /data/htcone/
getfacl: Removing leading '/' from absolute path names
# file: data/htcone/
# owner: htc1
# group: admin
# flags: --t
user::rwx
user:admin:rwx
group::rwx
group:admin:rwx
mask::rwx
other::---
default:user::rwx
default:user:admin:rwx
default:group::rwx
default:group:admin:rwx
default:mask::rwx
default:other::---

If I click on "Reset > Reset Permissions", ACL is modified this way:

getfacl /data/htcone/
# file: data/htcone/
# owner: guest
# group: guest
user::rwx
user:admin:rwx
user:guest:rwx
group::rwx
group:admin:rwx
group:guest:rwx
mask::rwx
other::rwx
default:user::rwx
default:user:admin:rwx
default:user:guest:rwx
default:group::rwx
default:group:admin:rwx
default:group:guest:rwx
default:mask::rwx
default:other::rwx

Why???
Isn't reset supposed to restore ACLs to configured settings?
How can I set ACL for /data/htcone/ content? If I modify "htcone" ACL settings from GUI, only /data/htcone/ is modified, not its content.

When I click on "Reset Permissions" I would expect something like this:

getfacl "$SHARE_DIR" | setfacl --set-file=- -R "$SHARE_DIR"
chown -R --reference="$SHARE_DIR" "$SHARE_DIR"

Am I missing something or is there a bug in permissions management?

[Jhael]

Similar problem here,

i configure a share (named data) with a certain users, all ok, but when i modify other share (named backup) users permissions when i click on ok button, the first shared (data) lost random user permissions, sometimes lost a user, another time lost write permission...

[DeeCee521]

Same here. Plus by the time they are accessed by the PC, they are marked as read only. I also get the long green line of death when accessing folders. None of this happened using radiator 4.

I've written support as I suspect that multiple guest accounts have been made by the NAS, but I can't see them. I also get user unknown if I try to change the permissions on the folder. Permissions have been an epic fail with this OS. I've been told it's because I don't understand how to do it correctly. That may be, but it worked on my ultra and NV+, just provide a clear guide on how to provide granular permissions for those of us who are not network IT and or Linux gurus.

TIA for any help persuading Netgear this is really a problem and with finding a clear cut solution.

Sent from my GT-N8000 using Tapatalk 4

[gregb_pro]

The RESET file permissions feature appears to have a bug in OS 6.1.4. Resetting file ownership to the specified share owner does not work. Specifically, "Shares -> Settings -> File Access -> RESET" in the ReadyNAS 516 OS 6.1.4 GUI interface resets to the system default, not specified user/group settings.

Try this test:
Create test user and test share. Establish Network Access and File Access as desired. Copy files into new share (I used "admin" user to load shares from backup). Note file ownership is "admin", then perform RESET. Files copied into a user share with "admin" ownership results in "Unix User\Guest" ownership after performing RESET, rather than specified Folder owner and Folder Group. Additionally, the file access control list may also (but not always) change from specified / configured list to R+W Everyone/Guest.

This was possible in ReadyNAS Pro RAIDiator 4.2.19 interface:

Set ownership and permission for existing files and folders in this share to the above settings. This option is useful in cases where you are changing security levels and need to workaround file access problems.

It is not clear OS 6.1.4 RESET has the same semantics (what exactly defines "default"?):

This option resets the security settings on all files and folders to the default setting. Network security settings, such as SMB and AFP access settings, will not be changed.
This option might be useful if users are incorrectly or inadvertently being denied access to individual files or folders inside the share.

Thanks, Greg

[DeeCee521]

Agreed

Sent from my GT-N8000 using Tapatalk 4