Dirk H. Schulz wrote on Thu, 08 Apr 2010 11:29:53 +0200: Can you please stop this? You are repeating your messages to the list with slightly changed subjects and content because you apprently don't get the answers you want. This is unfriendly, please stop this! And spare lame excuses. Did you consider to talk to the vsftpd author/list? I think it's obvious that your problem is easier solvable with/by them. > > -rw-r--r-- 1 root root 19968 16. Mär 11:24 Termine > > Leistungspr%FCfungen.doc > > -rw-r--r-- 1 ftpsystemuser ftpsystemuser 19968 16. Mär 11:24 Termine > > Leistungspr?fungen.doc In the other thread from two days ago you got an answer that you elected to ignore. But this answer may have a clue to your problem. If it is true that the file is first written as root and then rewritten (instead of chowned) to another user then the above can be the result of an encoding conversion problem. The filename contain umlauts and the first filename is uploaded with a %encoded name. I may be wrong but I think this encoding should be only transitory and re-transcribed to the characters fitting there in with the system's character-set when the file is written to storage. The % encoding for that character is correct, maybe the filesystem cannot or need not handle %encoding, but nevertheless tries to convert to an existing character instead of letting the "%FC" live as is. And this fails. What's obvious, is that the file then gets written with an unknown character in it. So, some part of the character conversion either doesn't work correctly or cannot work correctly, for instance because a character-set is set incorrectly on one of the involved systems and clients. If you used ASCII filenames the problem wouldn't exist, of course. This could be a bug in vsftpd or in the OS or a combination or in your client or something else. So, again, you should go to the source, which is vsftpd. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com