Migrated to Direct Admin server. Now, UTF-8 file names don't work. Ideas?

E

EivindFS

New member
Joined
Jan 18, 2011
Messages
8
Hi all,

I migrated a Wordpress website from a server running ISP Config to one running Direct Admin. There are a lot of files with UTF-8 file names in the media folder and they worked just fine on the old server.

On the direct admin server, the file names display correctly in my FTP client and the database migration also went without a hitch, but all URLs with UTF-8 file names on the direct admin server throw an error.

I use the file manager in the dashboard and navigate to the file. It displays correctly in the folder list, but when I actually click it, it throws an error where the file name is printed incorrectly (garble for the UTF-8 character).

I have searched Google and find nothing. Can somebody help me?

Thank you,
Eivind
 
Thanks for your reply, R1Lover

Well, that wouldn't do any good, because the problem is 100% due to the file system on the direct admin server.

No file on the server with letters like æ, ø and å can be displayed, even though I type in the exact correct URL for it.

What I got from the error message in the Direct Admin dashboard file manager was that it is not in agreement with itself on how these letters should be handled. As I said, the DA file manager shows them correctly, but when I click the file to view it, the error message shows a file name with garble for the UTF-8 character.

Is the problem a bit clearer now? The Wordpress info was for context only - it is in effect irrelevant.

E
 
Hello,

DirectAdmin is quite strict with which characters it allows for filenames.
Can you paste the name of the file that's being denied? I can look into adding any of the denied characters into the approved "special characters" list.

John
 
I was getting the same problem with special characters, like æ, ø and å, after upgrading to proftpd 1.3.3d. I paid a external company to fix the problem for me. This is what they told me they did to fix it:

"All we did after investigating was compile UTF8 into proftpd. Since your client checks if this is available and will encode (unicode) when it's available hence why it was working for me because my client already does this."

"Custombuild installs the RPM so we built it manually. My guess is before the recent proftpd patch (security) it had UTF8 support and since that it doesn't."

"Only directadmin can answer this as it's them that will decide weather to include UTF8 support or not. My guess is that by the time the next release is out someone else will have reported this bug and it will have been fixed so most likely."
Click to expand...

I sent this information to Martynas (smtalk) about 30 days ago, and he said he would fix this in custombuild. However, I don't know if that fix is applied or not. Is it? I don't think it is. :(

John, can you please check this out and give comment on it? Can you please add back UTF-8 support in Custombuild ProFTPD so that we can use custombuild and not have to build it manually every time?
 
Last edited:
I don't thing we "removed" it perse, but likely the custombuild version differs from the rpm versions. Custombuild does not install rpms, it installs proftpd from source, which is likely the difference... however, I've checked the spec file for proftpd and it doesn't look much different than the configure line we use in custombuild. After googling around I found that this is likely the option at the center of attention:
Code: 
--enable-nls
(correct me if I'm wrong).

In any case, I found quite a bit of fixes/changes with mention of this in the newer versions of proftpd, so it's possible that it was enabled by default before, without needing --enable-nls, but with the newer versions of proftpd, it does (this is just a guess.. since the configures are very close/identical and neither have --enable-nls).

In any case, I'll add --enable-nls to the configure.proftpd file and to the knowledgebase guides.

John
 
Hi zEitEr,

I included some screenshots with the error and the file causing it.

The error log doesn't show anything that seems relevant.

I'm afraid the posts of ditto and DA Support were a bit over my head. Could you possible explain a solution to me in relatively plain English?

Thanks,
Eivind
 

Attachments

  • utf8-problems.png
    utf8-problems.png
    25.5 KB · Views: 217
Hi zEitEr,

I too thought I was experiencing an Apache problem considering that just a normal file request using these UTF-8 characters fail.

But I'm not quite tech-savvy enough to know the difference I'm afraid.

----

Hi John,

The characters which are giving me a headache are currently æøåÆØÅ. But there could potentially be more (these are just the Norwegian characters, I also sometimes have file names with Swedish characters etc).

What would the change you are suggesting actually do? I would suppose I would have to update the DA software on my dedicated server with your change. Right?

Thanks for your help everyone,
Eivind
 
DirectAdmin Support said:
...I found that this is likely the option at the center of attention:
Code: 
--enable-nls
(correct me if I'm wrong).
Click to expand...

You are correct! When you added --enable-nls to the configure.proftpd file, it fixed all the problems we was having with special characters in file names. Please keep this setting for the future too, so that the problem don't return - we evidently need --enable-nls :)
 
EivindFS said:
The characters which are giving me a headache are currently æøåÆØÅ. But there could potentially be more (these are just the Norwegian characters, I also sometimes have file names with Swedish characters etc).
Click to expand...

John have now added --enable-nls to the configure.proftpd file, and that should fix your problem (if it was the same as my problem). All you should need to do now, is to recompile proftpd in custombuild:

Code: 
cd /usr/local/directadmin/custombuild
./build update
./build proftpd
 
You must log in or register to reply here.
Back
Top