ProFTPd Umask change has no effect

Submitted by signet on Tue, 08/11/2009 - 10:30 Pro Licensee

Hi,

We have yet another customer who wants to use his Virtualmin VPS as a FTP server (next to ordinary webhosting). He requests the following setup:

A Virtual Server named "engineers". Under this folder the following structure has to be made; Subfolders named after the project number.

In the subfolders the owner of the virtual server has to have read and write permissions. Next to that, every subfolder is used by a customer who only gets read permissions. In short:

engineers (r/w account of the virtualserver owner)

|

| | 5000 5218 (Read access for customers, r/w for the virtual server owner.

This is feasible I think. I need to change the umask within ProFTPd, that's all I think? So I changed this to 002 and applied the changes. But when I make a new user, the home directory still gets 644 as umask. What am I doing wrong?

Thanks!

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Tue, 08/11/2009 - 18:22

So the only issue is that the home directories of new FTP users are mode 644 instead of 644? Those don't get created by ProFTPd, but rather by Virtualmin ..

Or do uploaded files get the wrong permissions too?

Submitted by signet on Wed, 08/12/2009 - 02:13 Pro Licensee

Hi,

The issue is indeed that home directories of new FTP users are mode 644 instead of 664. I wasn't aware that virtualmin does create these folders, I was under the impression that ProFTPd created these.

Can I change the behavior of Virtualmin when creating new FTP users?

Thanks!

Submitted by JamieCameron on Wed, 08/12/2009 - 12:13

Virtualmin copies the home directory permissions from the domain's home, so you can change /home/engineers to mode 775 and this should apply to new FTP users.

Does that help?

Submitted by signet on Thu, 08/13/2009 - 03:11 Pro Licensee

Hi,

Yes! I changed the permissions and when I now configure a new FTP user the permissions are correctly.

Thanks!

Justin.

Submitted by Issues on Thu, 08/27/2009 - 15:18

Automatically closed -- issue fixed for 2 weeks with no activity.