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.

Thank You @harrymc for the useful Link. Here is the solution how i have solved this issue now.

I'm describing the permissions for the user. Use the Advanced Security dialog to add this permissions. ( Right click / Settings / Security / Advanced )

RootShareDirecory

• Permission for This Folder, SubFolder and Files only Read, Execute

ProjectFolderX

• Activate Permission inheritance.
• Permission for This Folder every permission excluding Delete.
• Permission for Only Subfolder and Files Full Access.

Explaination

In order to prevent a file from beeing moved, you have to disable the Delete. Unfortunately there are two values which influence if an folder can be deleted:

1. The Delete Permission on the folder it self
2. The Delete subfolders and files of the parent Folder.

Please ensure the user which is not allowed to delete, has none of these two permissions.