it would also help to know what FTP daemon your running? i'm thinking that some of them like proftp and vsftp have umask etc config options in them as well. might want to look at that as well, within the ftp server. Dave Sherohman wrote: > On Thu, Sep 18, 2008 at 06:19:10AM -0500, Jon Schewe wrote: > >> It depends on what you're getting. The umask isn't too hard, but I've >> found that it's far to unreliable as different people set it different >> ways. You can keep going down this path and what you probably want is this: >> Set the umask with "umask 002" this makes newly created files rw by >> user, rw by group and r by other. Then if you set the sticky bit on a >> directory all newly created files in that directory will have the same >> group as the directory. >> > > You have misremembered. To have all new files in a directory owned by > the same group as the directory itself, you set the sgid bit on the > directory. Note, however, that some applications ignore[1] this (many > of this set also ignore umask) and will create files with their own idea > of the "correct" ownership, often without providing a way to override > this (mis)behaviour. Given that the OP's issue is in respect to an ftp > arrangement, I suspect that the issue here is likely to be caused by > such an application.[2] > > The sticky bit, when set on a directory, makes the files in the > directory renamable/deletable only by each file's owner or the > directory's owner (and root, of course) rather than by any user who can > write to the directory. > > > [1] Or override, perhaps. I've never bothered to dig in and see whether > the file is initially created as user.wronggroup or created as > user.rightgroup, then immediately changed to user.wronggroup. > > [2] I also work with a Dreamweaver guy and have to constantly use su, > chgrp, and chmod to fix the ownership and permissions of files he > uploads because they end up being owned by him.him despite directory > permissions being set such that a shared group should own anything > created there and 0755 (rw-r--r--) despite his 002 umask. > >