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

[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... :evil:

[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]

brassmon wrote:
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.

[jaya]

I do have the same "parameter" errors . Even after working long with support with several work around... waiting for the new firmware ..

[Liberator21]

What is the status on the beta firmware?
Has anyone tried it?

[ReadySECURE]

It looks like there has been quite a bit of buzz on this post. I would like to provide a quick fix for the issue that I have discovered with the current (4.2.19) version of firmware. Under Share Listing > Share in question > CIFS > Advanced; set the owner to "nobody" and the group to "nogroup" (without the quotes of course) then check the set ownership and permissions to the above.... and then apply. This should release any ownership issues that may be causing the issue. Then go into Services > Standard File Protocols and disable; then re-enable the CIFS protocol. This is what fixed the issue for me.