Access denied when setting permissions to directory

I'm trying to set security permissions to directory located on my open-e server from Windows 2000.
When I try to do this, I get the message "Access denied.".
There are directories on the same share wich I can modify without any problem.
The permissions on the directories that give "Access denied" and on the directories that work are the same.
I'm logged on as the domain administrator. The group "Domain Admins" have rights to the share I created on Open-E.
The domain administrator has UID 0.

My domain-controller is a linux-samba server with ldap backend.

Please help.

With kind regards,


Robert Boers

Somehow this Windows 2000 machine does not or has inherited permissions set. If you can access other directories without a problem then you will need to find where these permissions have been set. Below are some examples on how permissions can be applied on a Windows system. Try them with a new directories and the existing one you are having issues with.

Also check your External LDAP server group mappings. The group mapping is part of the Samba SAM account information data and is stored either in the file /var/lib/samba/group_mapping.tdb (when using tdbsam) or in an LDAP directory (ldapsam) maybe different location on your server.

User rights and privilege information, together with domain access controls, are stored in the file /var/lib/samba/account_policy.tdb. ACL access controls on shares are stored in the /var/lib/samba/share_info.tdb.

As of Samba version 3.0.21, the account policy information will be stored in the LDAP directory when the primary passdb back end specified is the ldapsam. Samba versions earlier than 3.0.21 did not replicate policy information via the LDAP directory, thus making it necessary to manage policy settings on all domain controllers. Version 3.0.21 automatically replicates policy information to all domain controllers. The tdb files store binary hashed data, the contents of which can be dumped to a plain ASCII format using the tdbdump utility

Open-E supports Windows ACL (Access Control List) for read, write and execute
options are based on the POSIX standard written by SGI.

Some examples how to use ACL (with ADS or PDC authentication):
1. Deny access to a Directory for every user (group):

a. Create a new folder or select one of your existing folders (you must be the owner
or superuser to set ACL permissions)*
b. Go to the “directory properties” (right mouse click on the directory then choose
"Properties")
c. Select a the “security” tab
d. Choose the group "Everyone"
e. Click the "Remove" button – only you and your group will have access to the
selected directory **
f. Click the "Apply" button

Now only you have permissions to access this directory.
2. Allow full access for a group "WORK" to this Directory:
a. Make sure that the group WORK is created
b. In the security window click the "Add" button
c. Click the "Remove" button (point 1)
d. Select the group "WORK" (Advanced �� Find Now will show you all users and
groups) and click OK
e. Enable Full Control in the “Allow” column
f. Click the "Apply" button

3. Set “read only” permissions to the file for everyone:
a. Create a new file (you must be the owner or superuser to set permissions)*
b. Go to the permissions window
c. Select the “Everyone” group
d. Leave only a ”read” permission in "Allow" column
e. Click the "Apply" button
f. Make the same for your group and yourself

Now the group “Everyone” has "read only" permissions to this file.

4. Changing the directory owner:
a. On Open-E web interface go to resources �� shares
b. In the "Set Superuser" function select your user and restart connection
(maintenance �� shutdown �� Function Connections reset) or wait about 15 minutes
c. Go to the directory/file properties (right mouse click �� properties on the directory
and click the "security" tab)
d. Click the "Advanced" button
e. Select the Owner tab
f. Click the "Other Users or Group" button and select the user that will be a new
owner (Advanced �� Find Now will show all users and groups), click OK***
g. Select the user from the list and click OK and the "Apply" button
h. Click OK and re-open this window to refresh owner.

5. Allow a full access for the user "BIG BOSS" to this Directory

a. Make sure that the "BIG BOSS" exists
b. In the security window click the "Add" button
c. Select the user "BIG BOSS" (Advanced �� Find Now will show you all users and
groups) and click OK
d. Enable Full Control in the Allow column
e. Click the "Apply" button

6. Allow “read” access for a group "COMPANY" to this directory

a. Make sure that the group "COMPANY" exists
b. In security window click the "Add" button
c. Select the group "COMPANY" (Advanced �� Find Now will show you all users and
groups) and click OK
d. Enable "Read & Execute" in the Allow column
e. Click the "Apply" button

7. Make “read only” directory with a full access subdirectories for the group “ALL”
(using inheriting permissions)

a. Create a folder "ROOT"
b. Go to the security window
c. Remove both “Everyone” and “Your” group
d. Click the “Advanced” button and then the “Add” button
e. Select the “ALL” group and click OK
f. Change “Apply onto” to “This folder only”
g. In permissions leave only “Traverse Folder / Execute File” and “List Folder / Read
Data”. Click OK
h. Click once again the “Add” button and add ALL group
i. This time select “Apply onto” to “Subfolders and files only” (this step will submit
any inherited permissions)
j. Select “Full Control” and OK
k. Click “Apply” to save permissions.
With these settings users from the group “ALL” cannot remove the “ROOT” folder or
make any changes to its contents. All new files/folders will be created based on the
access given by inherited permissions.
Example:
- file /ROOT/some_file.txt can be changed but can not be removed
- directory /ROOT/directory can not be removed but a users from the group ALL can
create folders and files in this directory.
- file /ROOT/directory/my_file.txt can by removed and changed by the group ALL (if
inherited permissions wasn't changed)

8. Inherited permissions
If the file or directory has inherited permissions, all newly created subfolders will
inherit the main folder permissions. All permissions can be changed. Please keep in
mind that changing permissions in the main folder will trigger the same changes to
the inherited permissions of any subfolder within.

Hello Todd,

Thank you for your reply.
I understand the security permissions on Windows shares and directories.
That is not the problem.
The problem is that I have several directories on a share that don't allow me to change the permissions.
I'm already administrator and have access to this directories, but when I try to change the security permissions I get the error "Access Denied".
Normally I should be able to become the owner of this directory and set permissions.
But that also doesn't work.
I think that the directory with Access Denied is created by anonther user than Administrator.
On an normal Windows 2000 domain it's no problem to change the ownership and/or set security permissions, but on my system it is a problem.
A workaround is:

- Create a new directory with a different name.
- Copy all the data from the directory with the problem.
- Delete the directory with the problem.
- Rename the new directory to the old name.

After this I can set the permissions.

It's no problem to do this on a couple of directories, but we have this problem on all our shares in different levels of the directory-structure.

The question is how can I solve this problem for my complete system at once?

With kind regards,


Robert Boers

Depending how your rights are assigned you could use the Extended tools ctrl. + alt. + x to Reset the ACL's of files and directories or depending if you want full ownership of the files and directories use this option to Set owner. But this should be tested with a new share and set a different owner as not to disturb the existing rights to the directories that users have currently so you understand what is going on in your SAMBA server as this sounds like a preexisting condition. Please read the below statements and read the documentation of you SAMBA server on how this relates so you have a better understanding. We do not handle permissions only your server but this will help.

note:
Resetting ACL's will reset all file permissions. It works like chmod
777 in Linux shell and it is connected with file system.

Set owner of files is also connected with file system and it works
like chown in Linux shell.

Permissions in Web GUI are only connected with Samba, not with file
system.

Also have tried to enabled and set Superuser in the Function „SMB settings“.
This also sounds like there where previous permissions in the past and or the administrator security setting where updated and the SAMBA server is keeping them, the workaround that you are doing is proving this and you may have to continue with this process unless you change the authentication method Internal LDAP (import users and groups) to test UID 0. Also unless your External LDAP has some type of cryptography that has been update recently, which we do not support this could be contributing to issue.