Jeżeli to ma być serwis widziany w internecie (a nie coś w firmie, w wydzielonym LANie), to po prostu zapomnij o FTP. Niech sobie leży w swojej trumnie i powoli rozpada w proch.
Albo zastosuj SFTP (czyli de facto transfer plików przez SSH), albo postaw coś prostego na HTTP(S).
Przy okazji: scenariusz z możliwością zapisania plików bez możliwości usuwania czegokolwiek z folderu sugeruje jakiś poważnie błędne założenie w logice biznesowej. A co, jeżeli user nadpisze istniejący plik pustym? Niby nie skasował, a zawartości nie ma...
Robiłem test - zasadniczo uprawnienia rwsrwsrwt na katalogu powinny dać efekt "może stworzyć-nie może usunąć", przez to, że nowo tworzony plik ma automatycznie zmieniane uid (pierwsze rws) i gid (drugie rws) na właściciela katalogu i user nie może skasować pliku bo nie jest już jego właścicielem (rwt), ale niestety bit SUID nie działa tak jak powinien i uid pliku jest oryginany, w związku z czym prawo t nie zabrania skasowania tego pliku. Czyli generalnie - jak możę stworzyć, to może skasować - i wynika to z uprawnienia katalogu a nie pliku. Jedyne co mi przychodzi do głowy to demon chodzący na inotify, modyfikujący w locie uprawnienia pliku w momencie jego zamknięcia po stworzeniu. Ewentualnie rzeczywiście dopuścić FTP (BadIdeaTM), ale zablokować na nim polecenie DELETE.