Netatalk and special characters

mariourk

mariourk

I have a problem with netatalk. At first glance, it seems to work perfect. However, mac-users seem to be fond of using special characters, when naming their files and folders. And when these are stored on the server, weird things happen.

For example. A Folder named Kolsté will show up as Kolste??, when I look with ls, on the server. These directories and files tend to show all kinds of strange behavior. They keep disappearing and reappearing. Or they are shown twice. And when one is removed, so is the other.

As far as I can tell, there is a conflict with charsets. But I have no idea how to set this straight. I'm running FreeBSD 9.1 and netatalk-2.2.4,1

Anyone?
 
The special characters, you are talking about are UTF-8, which is a standard of character encoding that is around now for more than 20 years, and I consider this not at all special anymore.

Login to your server using a UTF-8 capable terminal, and your problems are solved.
 
The problem is not the terminal. Sure Kolste?? isn't really how it's supposed to be, but I don't care about that. It's the macs that go haywire. They have the problems I described.
 
mariourk said:
... It's the macs that go haywire. ...
Click to expand...

So, you are telling us, that when a Mac user creates a file named Kolsté on your server using his Mac over Netatalk, and ls on your server shows Kolst?? and in the directory listing in the Finder of the Mac user, the file appears sometimes doubly and sometimes not at all?
 
mariourk said:
Yes. When these characters are removed, all works well.
Click to expand...

OK, this is definitely unusual. Here are thousands of files/directories in shares on a FreeBSD 9.1-RELEASE server with file system names containing all sorts of German Umlaute, math. symbols, Portuguese and French accented chars., etc., and I never saw something like this. These files are shared by Mac clients via Netatalk to Windows clients via Samba and vice versa without any problems.

Did you change anything in /usr/local/etc/afpd.conf? Usually, afpd works well with the default settings, i.e. /usr/local/etc/afpd.conf being empty.

Did you set a dbpath in /usr/local/etc/AppleVolumes.default, if yes, does it exist?

Are there any error messages or warnings in /var/log/messages coming from afpd, cnid_dbd, and/or cnid_metad?

Are these problematic files accessed by users from different OS by different means, e.g. AFP, SMB, and/or NFS?

For example, if you changed in /usr/local/etc/smb.conf samba's unix charset parameter from its default value of UTF8 to something else, then strange things may happen when a Windows user and a Mac user share a file/directory having a filename containing characters higher than ASCII127.
 
This server is accessed by macs and windows machines too. The windows PC's seem to do fine. It's just the macs (Mountain Lion) that seem to behave strange. I found it hard to believe when some users complained about the problems I described earlier, but they actually showed me. Some folders kept disapearing en popping up again. Other folder were shown twice. When I renamed those folders, the problem was solved.

I tried to reproduce the problem with another FreeBSD 9.1 PC, but no luck so far.

* I did not change /usr/local/etc/afpd.conf
* I did not set dbpath in /usr/local/etc/AppleVolumes.default
* The logs show a lot of these errors. Maybe you are on to something there... :
Code: 
sys_getextattr_size: error: Result too large
deletecurdir: error deleting .AppleDouble in "/path/to/dir"
* These files can be accessed by windows PC's via Samba. But it's highly unlikely they did, because these particular files are no business to them. The folders contain indesign files, they can't use.

Maybe this is relevant. I copied all the data from an old Xserve, to this new fileserver. I did that with rsync. Maybe that screwed up some stuff? Like databases with metadata from the original server?
Code: 
rsync -trP --delete 'root@xserve.domain.com:/Path/To/Share/' /Path/To/Share/
 
I just got dragged to another case. This time the file had the à character in its name. It was impossible to open, copy, delete or rename this file. Renaming it in the terminal also didn't work, because the terminal (gnome-terminal) also couldn't handle the à. I was able to rename the à to a regular a, with a windows PC. After that, the file worked fine.

The odd thing is that I could rename it back to à with a Mac and it would still work fine. Apparently, something went horribly wrong when I rsynced the files from the old Xserve to the new FreeBSD server. It looks like all the existing files with special characers in them cause trouble. But once renamed, even with special characers, it works fine.

Can anyone explain this? And hopefully present a fix?
 
Well, that could be the case. But to be honest, I have no idea how to check that.

I also did a little test to see if rsync did indeed screw something up and that seems to be the case. I mounted the new FreeBSD server on the old Xserve (still running, but with filesharing disabled) and copied (drag and drop) that partcilar folder to a share on the new FreeBSD server.

Guess what? No poblem whatsoever. I could do anything with the files, on any mac. But when copied with rsync, or scp, there is trouble.
 
$ export LANG=en_US.UTF-8

$ ls -l /the/problematic/files

Make sure your terminal program is set to UTF-8 encoding.
 
You must log in or register to reply here.
Back
Top