I'm having trouble getting Proftpd to resume an interrupted upload, in the anonymous incoming directory, although I've allowed world write permission to the directory and set all the options (AllowOverwrite, AllowStoreRestart) in proftpd.conf per the documentation. My detail logs show that all goes as expected through the REST command, but then the STOR that the client sends next is rejected with a 550 code and the text "cannot overwrite file"...

The client is a special-purpose one I distribute to my customers (I recover munged Btrieve databases and many files are in the hundreds of MB), but it worked perfectly when I was using the "Serv-U" server under Win95. I think it was working initially with Proftpd also, but cannot vouch for that. However in the past week or so it's failing consistently. When a 5-MB upload via 56K dial-up gets disconnected after 2 hours, with only 100K left to go, the absence of the Resume capability is murderous (that happened yesterday).

Anybody have any ideas as to (a) how to find out exactly what's wrong and (b) how to fix it? I'll be happy to make the url available via private Email if anyone is willing to help me test it...

Are you shure you /etc/proftpd.conf contains :

AllowStoreRestart on
AllowRetrieveRestart on

Also try to chown -R nobody.nogroup $FTPHOME/incoming then chmod -R 7777 $FTPHOME/incoming

But i *wont* suggest that unless your running a lame warez server

I don't have AllowRetrieveRestart but I probably should. I'm a bit paranoid about security so I'm not about to give total permissions; in fact clients cannot even see a directory listing for "incoming" and that's the only place they can write...

The problem turned out to be trivial; I had created a test-case, and it did NOT have write permissions. Once I set it to have the same permissions as normal client-uploaded files, the restart worked as expected!

Thanks for the reminder that I need to be sure they can restart downloads if need be...