I've accidentally run this command

sudo mv /* /applications/minced/

instead of

sudo mv ./* /applications/minced/

This is all that's left in the root directory

$ /
applications/ dev/          proc/         run/          sys/          tmp/       

I still have an active ssh connection to the server. I've tried calling mv, sudo and chmod... directly from /applications/minced/bin/ or /applications/minced/usr/bin/, but nothing works, though I can locate them there using path autocompletion.

$ /applications/minced/bin/ls
-bash: /applications/minced/bin/ls: No such file or directory

I've read Revert moving root directory recursively, but mounting the system under LiveCD is not an option for me since it's a VPS, not a physical machine. Any ideas?


I figured out this is due to library linkage problems, so I did this

$ export LD_LIBRARY_PATH=/applications/minced/lib/x86_64-linux-gnu/
$ /applications/minced/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /applications/minced/bin/mv /applications/minced/* /

Obviously I ran into permission problems. Calling sudo with the linker throws this error

$ /applications/minced/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /applications/minced/usr/bin/sudo ...
sudo: effective uid is not 0, is /applications/minced/usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

As suggested by Barafu Albino, I've tried calling su with busybox (.../bin/busybox su -), but it throws su: must be suid to work properly. I guess this happens because su can't locate /etc/passwd and /etc/shadow. Seems like I've screwed up the system completely.

  • No, su and sudo are messes up because mv probably broke their permissions. You'll need to reset the suid permission on su and sudo to get them working. – casey Sep 30 '15 at 20:29
  • @casey I believe there is no way to do it without being root in the first place, is there? – Eli Korvigo Sep 30 '15 at 20:57
  • boot off a live dvd or rescue image and then fix your filesystem from there. – casey Sep 30 '15 at 20:58
  • @casey I've mentioned this approach in my question. I can't do that since the machine is a VPS. – Eli Korvigo Sep 30 '15 at 21:00

Your applications can not run because they want to find libraries and those are misplaced too. Try using busybox directly.

bin/busybox ls

should work as ls and so on.

  • I tried a similar approach by exporting linker path, i.e. export LD_LIBRARY_PATH=/applications/minced/lib/x86_64-linux-gnu/ and calling the commands manually /applications/minced/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /applications/minced/bin/mv /applications/minced/* /. But I no longer can sudo. – Eli Korvigo Sep 30 '15 at 10:10
  • So what about busybox? It has su in it, too. – Barafu Albino Sep 30 '15 at 10:11
  • 1
    su: must be suid to work properly – Eli Korvigo Sep 30 '15 at 10:14
  • I've updated the post to show what's happening. – Eli Korvigo Sep 30 '15 at 10:25
  • Yeah this option would've worked if I had root privileges left. Next time I'll login as root in case this stuff happens. Thank you – Eli Korvigo Sep 30 '15 at 10:50

Lets do another approach. I assume you do not know real root password. Here is a list of libraries that sudo needs:

linux-vdso.so.1 =>  (0x00007ffea6be9000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fbbad17b000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fbbacf78000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbbacd74000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbbac9aa000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fbbac73d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbbad5c5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbbac51f000)

Here is a list of files in sudo package (only relevant ones):


Try moving libraries to the binary, into the same folder. May be it will work. su has less dependencies, but requires to know real root password.

  • 1
    sudo and su won't run because they lost /etc/passwd and /etc/shadow. Thank you for your help, but seems like, I've screwed everything up too hard to deal with it. – Eli Korvigo Sep 30 '15 at 10:47
  • @EliKorvigo: They didn't lose /etc/anything. They lost the setuid bit when you moved them. They need that because you can't give the user root if you don't have root to begin with. – Kevin Sep 30 '15 at 14:53

I just run into this problem exactly like this post. I'm using an Ubuntu server which has a disabled root user and is using sudo to do the root commands. so I can't log in with root user by any chance, the only way for me in the instance is making the sudo works. unfortunately, hours passed, I failed, that's too bad.

And for users who can log in with the root, I suppose you guys forgot to mention another way which may be much easier: busybox sulogin

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.