Can’t change permissions – “The parameter is incorrect”

[Grievous]

Hi grievous
Any further suggestion which I can do?
Thanks

I just finished trying to reproduce it here on our end again, and it works for us.

Specifically I took a 2100 running 4.2.5, added it to a domain using windows 2003 server that has a bunch of users and groups, copied a bunch of data to the NAS, updated the NAS, set a restrictive permission for the domain users group(read only, unchecked the write permission on a folder), opened the folder and added members of the domain users group to the ACL list with full control. I get no errors, the permissions get applied, and the permissions are enforced as expected. Based on what I just told you that I did, am I missing anything?

(I would have responded to you earlier this morning, but it takes a while to get an environment reproduced sometimes)

[gn00347026]

Dear Grievious,

please found my PM, thanks alot~

[arunasad]

Grievous,

What is the status of the original issue? Is it fully resolved in the current RAIDiator version (4.2.17)?
I still have the same problems with old shares, but couldn’t reproduce it newly created test share. To fix this permanently do I need to recreate all shares and move the data, or it can be resolved with original shares?

[Grievous]

Grievous,

What is the status of the original issue? Is it fully resolved in the current RAIDiator version (4.2.17)?
I still have the same problems with old shares, but couldn’t reproduce it newly created test share. To fix this permanently do I need to recreate all shares and move the data, or it can be resolved with original shares?

The status would be that we can no longer reproduce it in 4.2.17. Yes, I'd advise creating a new share and copying at least a portion of the data over and checking that it works.

[hoverman]

I am having this issue as well, with two different customers. Once customer is user a 2003 Domain with an NVX, and the other on a 2008R2 Domain using a 2100. Both are running 4.2.17 of the firmware.

Only reason I came across this is both of my clients asked to change the permissions on a single folder inside of a share that is shared to "domain users". I went in the un-inherit permissions and then add only those domain users I wanted with Read/write. This seemed to work, but when users started complaining, I went back in to just reset everything back to normal, and then I got the infamous "Paremeter is incorrect".

I even went into the ReadyNAS frontView and went to the advanced tab and reset the permissions there. IT said it was successful but that one folder it didnt have an effect on. I did this on both users 2003 with NVX and 2008R2 with 2100)

I tried this on existing shares (created before the 4.2.17 updates) and on brand new shares (created today) and have run into the same issue.

I have read in other forum posts that this all goes back to having the "Domain Users" as the folder read/write group and that is I just make up a new security group, add the users to the new group, and reset all the permissions these issues go away. Can anyone confirm this?

If I dont hear by about 8 tonight, I will remote in to my customers and give this a shot.

[generalimaging]

I don't know if this has been resolved somewhere else...

I spent the whole freakin day researching this problem.. I found a solution that worked for me so I want to share it to save people time... It's a great product but the support for this problem is bad from the threads i've seen - even seeing the admin locking the thread because users were frustrated.

I'm using AD with a ReadyNas 2100. I'm setting up Department Folders (which means alot of different variations of permissions per folder)...

(i'm doing this from memory - but get the main idea) What I did was to go to the root folder --> get to the Security Tab and remove the Domain User account. Click Advanced and then remove the Domain User account from that screen... --> Check "Replace permissions entries on all child objects with entries shown here that apply to child objects." It will warn you but go ahead anyways.. If this works then I believe it will reset all the subfolders Domain User account permission. Click Apply....(There are 3 opportunities (screens) to click Apply during this process - i think you do it last, but try to click it before the last window if it doesn't work) My un-educated guess is that there are conflicts with the Domain User permissions on the subfolders that is preventing you to save the configurations on the Root.

The drawback is that you have to go back and verify all the folders' permissions (to be sure) and add Domain Users when needed.

I'm not a guru or anything, but I think the Linux file permissions are conflicting with Windows. I have a problem giving users Write permission without assigning Full Control with the NAS.. Anytime I click Write permission, it ends up giving the FULL Control permission - hence, i think it's the OS's permission conflicts behind this whole mess... Hope I helped.....

[generalimaging]

Forgot to mention that - after I reset the Domain Users permissions (from my posting above) - when I go back to the main Security window, I can't assign any permissions to Domain Users directly there. Instead, I click on Advanced and then Edit the Domain Users account and assign permissions from there. When you click Apply and go to the main Security window --> Domain Users will only have a check on Special Permissions, even if you give Full Control.. .. but it still should honor the permissions set on the Advanced window..

[Noia]

We're experiencing the same issue under certain conditions, which seem to be easily replicable, at least on our 18 TB ReadyNAS 3200

1) Create share default (no public access)
2) Under advanced, set user and group to domain account and domain group, keeping R/W for the group, and disabling Everyone
3) Take properties for the share, take the domain group, and change it from "This Folder Only" to "This Folder, Subfolders, and Files" in advanced.
4) "The parameter is incorrect"

This is probably by design somehow in the way that the NTFS access rights are used through this system, but it's MILDLY annoying. (Which means: My table has teeth marks at this point)
I can do it by using a separate group I guess, but I'm trying to avoid that for multiple reasons. Also, adding SOME groups, they just disappear again with no error, when hitting apply. (for instance adding a group for all users in a specific OU - I add, set rights, and it just disappears when hitting Apply)

Note that this is a setup with 800 local users (for our 6 OUs), in a global AD with over 200 OUs - from an enterprise point of view, it's not really giving me the options I need, sadly.

[Noia]

Even more odd - the only groups I can add have the prefix E130_ - all others just disappear. E129_, E131_, etc. - they all just disappear. Note that the NAS is located OU-wise in an OU called E130 - is there a problem adding groups from outside the same top-OU somehow? I can't see any other reason for this behaviour.

EDIT: Updating from 4.2.15 to 4.2.19 fixed the problem with the groups somehow, so that one isn't relevant anymore.

EDIT EDIT: Aaaand removed all the settings I had put on the shares, replacing the owner with the guy that added the NAS to the domain, and the group to "Domain Users". Changing them, they revert back instantly...

[brassmon]

Noia - I have seen having this issue as well but have not updated firmware. Did upgrading your firmware remove all individual file/folder permissions as well as ownership?

Thanks!

[Noia]

Noia - I have seen having this issue as well but have not updated firmware. Did upgrading your firmware remove all individual file/folder permissions as well as ownership?

Thanks!

Sorry about the slow reply.
Upgrading the firmware removed ALL rights on ALL shares - AND now the problem is back where I can't change access rights reliably, plus all users have again lost access despite the ACL showing them being correct. For the 215.772th time. I cannot explain exactly how unimpressed I am with this so-called business grade NAS.

[Liberator21]

I too have run into this issue. Support recommended I upgrade to .17 (Not .19) to fix an Iscsi connection dropping issue. After the upgrade, I can no longer create users in AD and point their home folder to the "Users" share I created on the NAS. I get the "Parameter Incorrect" error. Also, when I try to add users, or change permissions on other existing shares (Departmental drives), I get the Parameter Incorrect error! So far, no one has reported any issues accessing existing shares since the "upgrade" (to use the term loosely). I am just dead in the water when it comes to moving forward. However, I have been able to create new shares, and set permissions which allowed me to point user's home folders to this new share in AD. I don't plan on using this though, because I have no intention of adding more users to what I consider a broken box. This really worries me because I have about 100 user's home folders, a bunch of departmental folders, and an Iscsi connection to a Symantec Enterprise Vault email archive on this box! If this goes down, I'm screwed! Support seems to be taking stabs in the dark telling me to do some of the workarounds that are posted here. Considering the mixed results, I'm sitting tight until an actual solution is reached. Any word as to what's happening with this?
I have a Windows 2003 AD environment with XP workststions.

[Grievous]

I'm not sure why support would recommend 4.2.17 and not 4.2.19, considering how out of date .17 is. The current 4.2.20 t-28 beta has actually had some fixes for windows ACL issues since an earlier beta build. I suggest checking that.

[Liberator21]

The support person said there had been some issues regarding Iscsi connections dropping with .19, so recommended going to .17.
Here's the case number:17495725. When is the new firmware coming out of beta?

[Grievous]

We're looking into why support said that, you should definitely be running 4.2.19 and not 4.2.17 at this point.

I don't believe we have a timeframe for a final build of 4.2.20 at this time, however in it's current beta form it is stable enough to be put into place in a production environment, especially considering that the alternative would be permissions not working correctly. If you want to make absolutely certain that it fixes it without touching anything else and maintaining your ability to downgrade, update to the latest beta, create a new share and test your permission changes in that first.