vsFTP Server denies Folder Permissions after some minutes!

Started by GrehieL, January 31, 2021, 08:57:38 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

GrehieL

Good evening..
I have set up a vsFTP service on my VPS running Ubuntu 20.04 with KDE Plasma GUI.
After I make all the settings required to set user,permissions etc
when I login to the sftp using Filezilla the first 2 to 3 file manipulation I make the ftp client returns with messages such as permission denied.
It is very strange to me that everything looks good,working good but after some file copy-paste delete actions the ftp client refuses after that to serve my requests.
I am on wall right now what is this that creating this behaviour.
Please keep in mind that my level is more to begineer when coming to Linux but I keep reading and searching every bit of code to figure out and learn what I am doing.
Thanks in advance and excuse me for my poor English.

nil

Make sure /etc/vsftpd.conf has the line

write_enable=YES

E.g. edit the file as administrator:

sudo vi /etc/vsftpd.conf

If the line is commented, delete the # at the beginning of the line - move the cursor over it and press x to delete that character. Then save the file and exit with the command :wq

then terminate the daemon e.g.

sudo killall vsftpd

The daemon should start again automatically on its own, loading the new configuration. Then retry with filezilla and see if you still get permission errors
Do not communicate by sharing memory; instead, share memory by communicating.

--Effective Go

GrehieL

Thanks for your quick reply...
I've check for remark and it's comment as you suggest so these errors somehow "forgetting" my user's file permissions is not from this piece of code.
I have tried also changing umask to 002 but with not any result.

nil

To clarify, if /etc/vsftpd.conf contains a line like this

#write_enable=YES

That is "commented". The # indicates that the rest of the line will be ignored.

To "uncomment" it, remove the # like this

write_enable=YES

save the file, close the editor, then restart the vsftpd process. If your operating system uses systemd you can restart the process with

systemctl restart vsftpd



Do not communicate by sharing memory; instead, share memory by communicating.

--Effective Go

GrehieL

After a lot of trial and error I figured out the problem was that every new created file or folder inside the /ftpdirectory were changing group ownership automatically to the user that added that files-folders.
I managed to set all newly created files-folders to be set down to ftp group ownership no matter who user, which of course belongs to the ftpgroup,created that files by these commands
chgrp -R groupname /ftpdirectory (to be sure everything is in the correct place)
and by using setgid
chmod g+s /ftpdirectory
After these changes until now and with many tests no issues so far.
I don't know if this action is the correct one but seems to work.
I have posted it for any future refference by any whom might find it usefull.
Thank again for your concern and effort to help.  ;)