> > The Problem: the client writes files to a shared directory, which is 5 > directories deep from his DFS home directory. He owns the directories up to > the third directory deep, where he sets symbolic links to access the shared > directories. He writes files to the 5th subdirectory. Inspection of the > files here shows him as the owner but with read/write access only, even > though the DCE ACLs are set with owner's full permissions, this is rwxcid. > > He can not delete these files from the samba session, but he has no > problems deleting them from an AIX session. The path followed is the same > on both, samba and AIX sessions. >
I just encountered this problem a few days ago when testing 3.0.23d with DFS. I think the problem is that Samba tries to determine if the user can delete the file before actually deleting it. Since Samba doesn't know how to read DCE ACLs it only checks the ownership/mode bits of the files parent directory. If the user trying to delete the file is granted delete authority through the directory but does not have write authority via the mode bits the delete will fail. > I added the "acl check permissions = false" just to check, and he is > able to delete files, but this could be dangerous because people will be > able to delete files on directories they don't own. I tried deleting files > not owned by his id, and I was able to. Somehow, this tells me the problem > could be a configuration problem. > I just read the documentation for "acl check permissions" and I think it is in place for just this situation. The way I read it Samba will still change to the user when trying to delete the file, it just won't try to emulate the kernel access check on its own to provide proper Windows semantics. John Janosik [EMAIL PROTECTED] -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
