NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Can’t change permissions – “The parameter is incorrect”
I have three ReadyNAS Pro Business boxes on Windows Server 2003 domain.
Just noticed that there are some issues with changing permission on Windows machines. Basically if a user creates a folder and then he or an administrator tries to change some permissions (add additional user, propagate permissions to child objects, allow or disallow inheritance) this fails with error
“An error occurred applying security information to: <path/folder> The parameter is incorrect”
Or:
“Unable to save permissions changes on <foldername> The parameter is incorrect”
The same happens for the domain administrator account which was used to add ReadyNAS to a domain.
If I try to add additional user this actually works even after the error is displayed, however it doesn’t propagate down and only affects one folder.
This definitely used to work so I suspect problem occurred after one of the recent firmware updates. I am currently on 4.2.13, but the same was happened on 4.2.12 (just upgraded hoping this would sort the problem).
Also, this seems to affect only newly created folders. With old folders everything works fine.
Any ideas how to fix this?
Just noticed that there are some issues with changing permission on Windows machines. Basically if a user creates a folder and then he or an administrator tries to change some permissions (add additional user, propagate permissions to child objects, allow or disallow inheritance) this fails with error
“An error occurred applying security information to: <path/folder> The parameter is incorrect”
Or:
“Unable to save permissions changes on <foldername> The parameter is incorrect”
The same happens for the domain administrator account which was used to add ReadyNAS to a domain.
If I try to add additional user this actually works even after the error is displayed, however it doesn’t propagate down and only affects one folder.
This definitely used to work so I suspect problem occurred after one of the recent firmware updates. I am currently on 4.2.13, but the same was happened on 4.2.12 (just upgraded hoping this would sort the problem).
Also, this seems to affect only newly created folders. With old folders everything works fine.
Any ideas how to fix this?
137 Replies
Replies have been turned off for this discussion
- Even prior to t-33(meaning 4.2.15) there was only 1 windows system we were able to reproduce this with, and it no longer does it in t-33 with shares and folders created after updating. Unfortunately I've only received feedback from 1 person so far, who factory defaulted the system before we could get logs or anything from it.
Grievous wrote: Even prior to t-33(meaning 4.2.15) there was only 1 windows system we were able to reproduce this with, and it no longer does it in t-33 with shares and folders created after updating. Unfortunately I've only received feedback from 1 person so far, who factory defaulted the system before we could get logs or anything from it.
What's different in that 1 windows system vs. the other working windows systems?
I'm leery about putting a beta firmware on a production NAS, but if it provides useful information to resolve the problem, then I'll see what I can do. What information are you needing before/after the update?Conn wrote: Grievous wrote: Even prior to t-33(meaning 4.2.15) there was only 1 windows system we were able to reproduce this with, and it no longer does it in t-33 with shares and folders created after updating. Unfortunately I've only received feedback from 1 person so far, who factory defaulted the system before we could get logs or anything from it.
What's different in that 1 windows system vs. the other working windows systems?
Absolutely nothing, that's the problem. We're talking about windows servers that get re-formatted regularly, and these particular systems had windows installed, dcpromo run and the same domain configurations used(other than the domain names), and then windows update, with zero changes to things like domain policy. This is also why there's a handful of people with this issue and not thousands.
One thing to keep in mind with 4.2.16 t-33, is that you cannot downgrade back to 4.2.15.Grievous wrote: Absolutely nothing, that's the problem. We're talking about windows servers that get re-formatted regularly, and these particular systems had windows installed, dcpromo run and the same domain configurations used(other than the domain names), and then windows update, with zero changes to things like domain policy. This is also why there's a handful of people with this issue and not thousands.
Well I feel special now.Grievous wrote: One thing to keep in mind with 4.2.16 t-33, is that you cannot downgrade back to 4.2.15.
Thanks for the heads up. I won't be doing the update if I can't roll back in case something else messes up.- I'm in the same boat. We have 50 servers backing up to this device so I can't put the integrity of it in jeopordy with beta firmware. It runs well, minus this permissions issue. Luckily, our backups run as the same user account each time so the data does not need multiple sets of permissions. We only have a couple of shares with that requirement and they do not justify putting the rest of the system at risk.
Unfortunately I will be waiting until an official release (or until I can get my hands on another ReadyNAS that I can test with).
I will say though that the "handful of people with this issue and not thousands" might be misleading. That assumes that the thousands of people are using these devices with multiple permissions set on multiple shares. I would venture to guess that most users are probably using much simpler permission structures. jyarborough wrote: I'm in the same boat. We have 50 servers backing up to this device so I can't put the integrity of it in jeopordy with beta firmware. It runs well, minus this permissions issue. Luckily, our backups run as the same user account each time so the data does not need multiple sets of permissions. We only have a couple of shares with that requirement and they do not justify putting the rest of the system at risk.
Unfortunately I will be waiting until an official release (or until I can get my hands on another ReadyNAS that I can test with).
I will say though that the "handful of people with this issue and not thousands" might be misleading. That assumes that the thousands of people are using these devices with multiple permissions set on multiple shares. I would venture to guess that most users are probably using much simpler permission structures.
Yes, most users indeed have a simpler permission structure. That said, you're not necessarily factoring in the number of times questions about complex permission structures have come up, with how many ReadyNAS systems there are out in "the wild". But that's not a concern at the moment.
That said, if it was so easy to reproduce, it wouldn't have been so complicated for us to get a box that could reproduce it(which would be 1, out of many), and every windows box we have would be able to do it.
If this is just going to go back to bickering, I'm just going to lock the thread again. I unlocked it because I had more information, and left it unlocked so we could discuss the matter. Not so people could make guesses about how many people there are with a similar configuration. You either get "Grievous, that guy who wants to resolve the issue" or "Grievous, the forum admin who isn't here to argue", not both.- Sorry, didn't mean any disrespect. Was just thinking out loud. I definitely appreciate the work being done and if there is anything I can do to provide information from our environment I would be more than happy to do so. I really like that guy who wants to resolve the issue :)
- Hello,
I was wondering if there is a workaround? The problem is still there in 4.2.16.
Thanks,
Vincent - The only workaround I have found, which works for our situation but may not for yours, is to go in through the share properties in the web GUI and reset the permissions in the advanced tab. We have a pretty simple setup and do not have individuals accessing our devices, just service accounts for backup or administrators to manage them. I've found that if we create a group called admins and assign all of our admin and service accounts to it, and then reset the permissions on the share where the admins group has read/write/owner on the share, things work for us. I have no idea how it would work if we had complex permission strucutres.
From what I can tell, each file/subfolder that gets created in the share gets set to block inheritance and the only user with permission to change it is the user that created it. If we try to modify the permissions on the file/subfolder by using Windows Explorer we get the error mentioned at the beginning of this thread. We do seem to be able to modify the permissions on the share folder itself from Windows Explorer, but it doesn't actually seem to apply to the files/subfolders. - We purchased two of these devices and we cannot get users in our domain to write to subdirectories.
\\NAS-Server\Share can copy to but \\NAS-Server\Share\dirname we can't.
I have tried to set permissions and sometimes I get "THe parameter is incorrect" but other times it goes through.
All permissions allow THis folder, subfolders, and files.
ANy help appreciated as we cannot put into production until resolved.
THanks in advance.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
