Out of the box, proftpd-1.3.3d from DroboPorts.com comes configured to run as nobody:nobody, but even if I configure it to run as root I am unable to browse directories with 700 (owned by root) permissions. ProFTPd sends back a 550 error (no such file or directory), and my FTP client reports “Error -125: remote chdir failed”.
This is a problem for me, because the files created by Mac OS X when writing to a share on my Drobo FS via AFP are all set to 700. Is there any way to configure ProFTPd to access those directories?
Actually, the account under which the proftpd daemon runs is not very important. It is the norm to run it under a very restricted account so that if it gets hacked, the hacker only has access to a very-low privilege account.
What matters is the account with which you login. If you are logging in with ftpuser, then it is normal that you are not able to access root-only files.
There are two ways you can handle this:
changing AFP’s configuration to set the permissions to something more reasonable (say 644, or even 664 with the group being something else than root)
logging into proftpd as root
To log as root, change the “RootLogin” configuration item to “on”:
I’m not sure how you can change AFP’s permission mask, but from what I can see, my AFPD runs as nobody too (see /etc/netatalk/netatalk.conf).
A quick glance at the netatalk configuration on my FS gave me this (from /etc/netatalk/AppleVolumes.default):
[code]# perm -> default permission value OR with the client requested perm
dperm -> default permission value for directories OR with the client
fperm -> default permission value for filesOR with the client
But it seems that the actual netatalk config is in another file (/mnt/DroboFS/System/netatalk/conf/AppleVolumes.default), which is generated from /mnt/DroboFS/System/DNAS/configs/shares.conf, which unfortunately does not contain permission information.
You could try to edit /mnt/DroboFS/System/netatalk/conf/AppleVolumes.default and restart the netatalk daemon, but I’m not sure how well this is going to work, or even if this is going to survive a reboot.
For the moment I’ve modified ProFTPd’s passwd file to map ftpuser (which I’ve actually renamed to something else) to the system root user (0:0). For added security I’ve also set TLSRequired to on so that an encrypted connection is required. This is working for me until I find the time to experiment with changing the AFP permissions mask.