I have file with greek or cyrillic characters.

It is not owned by me, but by the web server user (www).

I cannot use the shell as the web server user (www) or as root, but I've used a script (executed by the web server user) to set the modbits directory it is in to 777 and the file itself to 666.

I am not able to rename (or delete this) file. Even using the inode and using find fails:

$ ls -i1
19120017 Idezbox - коробка.jpeg

$ find . -inum 19120017 -exec mv -i {} sane \;
mv: cannot move `./Idezbox - коробка.jpeg' to `sane': No such file or directory

Wildcards fail:

$ mv Idezbox*.jpeg sane
mv: cannot move `Idezbox - коробка.jpeg' to `sane': No such file or directory

The following Perl-script also fails:

find . -type f -print0 | \
perl -n0e '$new = $_; if($new =~ s/[^[:ascii:]]/x/g) {
  print("Renaming $_ to $new\n");
  rename($_, $new);

It prints out:

Renaming Idezbox - коробка.jpeg to Idezbox - xxxxxxxxxxxxxx.jpeg

but the subsequent rename command has no effect.
However, note that there are 7 greek characters and 14 "x"-es.

Moving to the directory above and trying to delete "Junk":

$ rm -riv Junk
rm: descend into directory `Junk'? yes
rm: cannot remove `Junk/Idezbox - коробка.jpeg': No such file or directory

Some requested output:

$ mount | grep "on /ifi/asgard/k00"
asgard:/ifi/asgard/k00 on /ifi/asgard/k00 type nfs (rw,tcp,rsize=32768,wsize=32768,hard,intr,addr=xxx.xxx.xxx.xxx)

$ df .
Filesystem           1K-blocks      Used Available Use% Mounted on
                     104857600  53201568  51656032  51% /ifi/asgard/k00
$ ls -al
total 88
drwxrwxrwx  2 www     ifiweb   4096 2014-08-11 14:16 .
drwxrwsrwx 14 inf5270 inf5270  4096 2014-08-11 14:15 ..
-rw-rw-rw-  1 www     ifiweb  35176 2012-04-14 13:38 Idezbox - коробка.jpeg
-rwxrw-r--  1 gisle   ifi-a     139 2014-08-11 14:15 perl-rename.sh

$ who ami i
gisle    pts/122      2014-08-11 11:37 (safir.ifi.uio.no:13.0)

After having read through all comments and answers (thanks everybody!) I no longer think this is just about escaping or quoting the cyrillic characters. I need to look into the NFS angle.

Edit 2015-10-02:

The problem turned out to be NFS-related. Since the file was created directly on a NFS-mounted volume, which I accessed from another computer, nothing worked. Logging directly in on the server as root allowed a sysadmin (I am a mere user on this particular system and can't do this) to delete the file (using some standard method to escape the Greek characters). Kudos to G-Man for putting me on the right track (in a comment). If G-Man is still around and converts his comment into an answer, I'll accept it.

  • 1
    What about vidir from moreutils?
    – MadTux
    Aug 11 '14 at 11:37
  • 2
    Can you edit the question to show the output of mount, df . and ls -A. Aug 11 '14 at 11:44
  • 3
    @FreeRadical Then you must have some alternate problem as well, it is not a simple "how to quote"-problem.
    – peterh
    Aug 11 '14 at 11:59
  • 2
    Can you add the output of mount, df . and ls -A to you question. They are probably of relevance. Aug 11 '14 at 12:01
  • 3
    Did you create the file from your RHEL computer? I suspect that the problem has to do with the interface between your client and the NFS server. It may be necessary to login directly to the server to manipulate the file, or at least access it from a workstation running a different OS. (You know, the one whose name begins with 'W'.) Aug 11 '14 at 17:02

I know this is old but if you're looking to rename a file with weird characters, you can use:

find . -inum INODE -exec rename {} NEW_NAME \;

So in this case you could have used:

find . inum 19120017 -exec rename {} sane \;
  • Thanks for replying. However - I tried using find INODE with mv and it failed. I doubt rename would have worked better in this case. It has been resolved, so I'll update the question. Oct 2 '15 at 1:51

Your question indicates that this problem file is on an NFS-mounted filesystem, and nothing you do from your RHEL client successfully touches the file.  This suggests that the problem has to do with the interface between your client and the NFS server.  It may be necessary to login directly to the server to manipulate the file, or at least access it from a workstation running a different OS.


Not taking into account the NFS part of the problem, some days ago I had a similar issue while trying to delete a file with no name / blank name. Well, actually, it was not blank - its name was the octal code for the end of transmission character (\004). How it was created in there, no idea. However, what I did to remove it was to echo its filename and then pass that using xargs into the rm command.

  1. First, I got the real name by running

    ls -lb

    That will show the octal name for the files in the directory. In this case, \004.

  2. Then, I ran something like this:

    echo "\004" | xargs rm 

That was my workaround - maybe you can try something like the above, but using the entire filename (Idezbox - коробка.jpeg) in octal.

  • 2
    almost definitely it is the nfs part of the problem that is the problem.
    – mikeserv
    Aug 12 '14 at 6:04
  • ls thinks space and cyrillic is printable (which it is), so ls -lb didn't show a name different from the one I've already got. Also tried to write the entire name as escaped octals, but no luck. Aug 12 '14 at 16:12

As workaround, and if the files are distinguishable by the ascii characters, try renaming the file using wildcards, i.e.

mv Idez*jpeg renamed.jpeg


@pacoseventeen 's answer was basically correct, I think you just need to enclose the braces with double quotes. I wouldn't use rename since that's for bulk renaming.

find . -inum INODE -exec mv "{}" NEW_NAME \;

I just used this on a file named ?? that ls -Q identified as "\033\033".

  • Nope - this does not work across file systems when the file you want to remove is on an NFS mounted volume. Please reread the question. Feb 21 '16 at 9:56
  • My answer foolishly assumed you had permission to rename the file in the first place. Mea culpa for not reading thoroughly. However, I don't think your comment is fair. I believe looking up inodes on NFS works just fine. Actually, if it is a permission issue, I wonder if you can re-frame the question after the fact.
    – realgeek
    Feb 22 '16 at 21:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.