though the group owns it
No, group does not own a file in a sense that the permissions for owner
apply. Owner permissions apply only to owner - the user; and group permissions apply to the assigned group.
If a user is the owner of a directory why can't he write to it?
He can, except that ftpuser
in your case is not the owner.
Most likely, because you don't say it explicitly: root
or www-data
is the owner /var/www
of the file, and ftpuser
is a member of the group www-data
.
Even if the user www-data
and the group www-data
have the same name, they are different entities for the operating system.
Can a user of a group give the group write permissions to a folder owned by the group himself?
Again: folder is not owned by a group. If the group has write-permission, any member of the group can change the permissions to the object.
Where is the group defined in the command sudo chmod -R 770 /path/to/the/directory
The second 7
refers to the group permissions (7
is a combination of read
, write
, and execute
).
Won't this give recursive permissions to all users?
It will assign (recursively):
read
, write
, and execute
for the owner (first 7
)
read
, write
, and execute
for the group (second 7
)
- no permissions for other users (last
0
)
As a rule of thumb, you should avoid explicit DENY rules in ACLs. If one is required, it is often because the data is already structured wrong.
The ability to delete or rename a folder is not decided by the Delete
permissions on the folder in question, but by the Delete subfolders and files
permission on the parent folder. This is counter-intuitive and different from how permissions for a file work. It definitely doesn't work as you would expect.
Let's use the following folder / file structure as an example:
FolderA
File1
FolderB
File2
FolderC
File3
FolderB
and File1
are in parent FolderA
. FolderC
and File2
are in parent FolderB
and so on.
Now, if we remove the Delete
permission from File1
, File2
, or File3
, for any user, that user will be prevented from renaming and deleting the file. This is also true if you use an explicit DENY Delete
on the file.
However, if you remove the Delete
permission from FolderA
, FolderB
, or FolderC
, for any user, that user will still be able to rename and delete the folder. This is also true if you use an explicit DENY Delete
on the folder.
Why is that? Because the Delete
permission is a permission that applies to files, not folders. Instead, we must remove the Delete subfolders and files
permission from the parent folder to accomplish what you are asking.
In our above example, we will need to remove the Delete subfolders and files
permission from FolderA, for a particular user, assigning the permission to this folder only
. In that case, the user will then be unable to modify FolderB
and File1.
The same is true if you use an explicit DENY Delete subfolders and files
on FolderA
instead.
The user can still rename and delete FolderA
unless the parent of FolderA
has also restricted that permission. As long as you applied the permission to this folder only
then the user will continue to be able to read/write/modify File2
, FolderC
and File3
.
The obvious drawback here is that it takes 2 levels of folders to accomplish what you are asking. In your case, you mention that you are trying to protect a Dropbox folder. So, your folder structure would have to look like this:
Dropbox
Protected Folders
File1
File2
FolderA
Protected Files
You would remove, for a particular user or group, the Delete subfolders and files
permission for this folder only
on the Dropbox
folder. You would then add or maintain, for a particular user or group, Full Control
or Modify
permissions for subfolders and files
on the Dropbox
folder.
Now the affected user will be unable to modify any files or folders immediately below the Dropbox
folder, but will be able to modify all files and folders contained in any subfolders.
There is an additional concern here with Dropbox, because this is not a normal folder. The Dropbox application expects full control of the Dropbox
folder. Being that Dropbox often runs as the logged on user, you can't prevent the logged on user from having full control of the Dropbox
folder. You can try it, but the results may be unpredictable and chaos is likely to ensue.
Best Answer
You might consider trying to run the command prompt as Administrator (Right click on a shortcut for command prompt, and choose that option) and delete the folder from the command line.
Switch to the parent directory, and do a
del /S /Q "FolderName"