Here is a link to the section in the ROX-Filer manual that contains information for a possible workaround:
On Sun, Oct 21, 2012 at 3:12 PM, thilo <email@example.com>
I just encountered the following problem: after copying several
images (each named ".DirIcon") into different directories on a
NFS mount, my ROX-Filer (2.11) Window does, as expected, show
some of them instead of the default folder icon, but not all.
I discovered that for ROX-Filer to show the new icons, both the
directory (on the NFS mount) AND the corresponding .DirIcon
must be owned by myself. This is a bit surprising, since both
directories and .DirIcons are world readable.
This can be reproduced: as soon as the directory or the
.DirIcon are not owned by myself, the Filer displays the
default folder icon.
I copied the directories onto a local ext4 filesystem and
played with the ownerships. Everything's allright, ROX Filer
always shows the .DirIcon images.
I am not at all sure that this would be a ROX Filer problem,
may also be related to NFS or something completely different.
However, as both the directory and the .DirIcon are readable,
the filer should IMO display the new icon.
I think that you're not quite correct. I've been doing some playing around on my TinyCore Linux box and it doesn't seem to be an issue with readability, but rather an issue of writebility.
If the directory is world-writable then the .DirIcon isn't used, but the world-write privilege on the .DirIcon doesn't matter.
On my machine, if I'm a non-privileged user and the Directory and .DirIcon are both owned by root and universally readable; then everything is fine. As soon as the directory is world-writable then the default icon is displayed instead of the custom one. It doesn't matter if the .DirIcon file is world-writable as long as the directory isn't.
Is this info helpful?
It seems to be some sort of security feature. The side effect is that you can't have AppDir or use .DirIcon on a drive that has a format that doesn't support file permissions. (e.g. NTFS )