2

I am using Ubuntu-Mate 20.04 and I have lost most of the contents of my home folder. I think it could be due to using wrongly the “rm” command with sudo, but not sure if it might be something else.

I explain: I was trying to delete a folder ( “targetfolder (something)” ) and its contents at /home/user2 while being logged as user1 (user1 has sudo privileges). So, I did:

sudo rm -r /home/user2/targetfolder (something)/ 

At first rm gave some error messages due to the parentheses - I mean this: ( ) -, so I substituted part of the folder’s name with *, and did:

sudo rm -r /home/user2/targetfolder */

NOTE: I perhaps used quotes for the name of the folder because of the blank spaces ( 'targetfolder *' ), though last command registered in terminal goes without quotes.

As I understand it, rm should only have deleted any folder with a name starting with “targetfolder” within the home folder of user2, but it seems to have deleted the major part of the home folder of user1. I add that as I was not clear if rm was working or not I closed the terminal killing, I guess, the process.

Just in case it is relevant, both user1 and user2 home folders are encrypted using ecryptfs (the folder to be deleted at /home/user2 was outside .Private and, therefore, unencrypted).

So, my question is if the rm command as I used it could have deleted the contents of the home folder of user1 (or even affected the system).

I have a recent backup of the lost contents, but I wanted to make sure it is not due to some problem other than the rm command.

Thanks in advance and sorry for my English.

9
  • 10
    /home/user2/targetfolder */ would have been parsed as two separate things to remove: first /home/user2/targetfolder and then */ - the latter matching by default any non-hidden directory in the directory in which the command was run Aug 15 at 0:49
  • 2
    rm -r is unforgiving and extremely dangerous if you make a mistake. It will permanently delete anything in the paths you specify as well as any other directories and files under that path. FYI- it's not necessary to use sudo for file operations under your own home folder. Restricting sudo to only when you actually need it could prevent you from making a catastrophic mistake, although it may not have helped in this particular situation if you ran these commands in your home folder.
    – Nmath
    Aug 15 at 1:37
  • 7
    You were wise to have a backup. Well done.
    – user535733
    Aug 15 at 2:00
  • 2
    rm with a -i as an option will ask you about each file before it removes it. Set up an alias in .bashrc to do this automatically if you like it all the time.
    – ubfan1
    Aug 15 at 4:05
  • 2
    "NOTE: I perhaps used quotes:" Type history and make sure what you did We like facts ;-)
    – Rinzwind
    Aug 15 at 8:51

1 Answer 1

9

This command

sudo rm -r /home/user2/targetfolder */

would try to delete a folder /home/user2/targetfolder, which probably did not exist, and then items matching */. That would mean all non-hidden directories (and their contents) present in the current working directory. If the current working directory is the home directory of user1, then yes, that is the one that would be affected.

The mistake is not escaping the space. A space is a delimiter separating arguments. Here, you provide two arguments (next to the option -r), /home/user2/targetfolder and */, where the latter is expanded by the shell to match all non-hidden subdirectories (e.g. Documents/, Videos/, etc.)

Quoting the file name pattern, or escaping the space, as in

sudo rm -r "/home/user2/targetfolder "*/

or

sudo rm -r /home/user2/targetfolder\ */

would have included /home/user2/targetfolder (something)/ and other matching folders if any.

In general, such use of rm -r, and then in combination with sudo is, as you experienced, extremely dangerous. Do not immediately execute such command but verify first.

  • Substitute the sudo rm -r by ls -d. That will list all the items included in your arguments, and allow you to verify what will be removed on beforehand (Thanks to cocomac for the tip).
  • Once ls lists what you expect to remove, press to recall that command and change ls -d into sudo rm -r.

If a single directory must be removed, avoid using wildcards altogether. Use tab completion. This way, you are sure the specific name is correctly entered on the command line.

7
  • Side note: you can also test that type of thing with the ls command. For example, doing ls /home/user2/targetfolder */ would have showed what would been matched by the wildcard
    – cocomac
    Aug 15 at 15:29
  • (Part I) Thanks a lot for all the comments and good information, in particular regarding what the correct syntax for the command would be, as indicated by vanadium. From what steeldriver and vanadium say, I understand that I have deleted almost all the home folder of user1, but that the system folders/files should be fine. As user535733 say, I was certainly lucky to have a backup. Aug 15 at 17:02
  • (Part II) I confirm I was able to delete the referred folder navigating (as superuser) to ``` /home/user2/ ``` , as was indicated by @vanadium. I don't know if there is another way to do it, but I did first ``` sudo su ``` and at the ``` # ``` prompt, ``` cd /home/user2 ``` (I did not place a slash at the end, but it worked, so I assume it is not necessary) and then, using tab to autocomplete the file name as suggested by @vanadium, ``` rm -r ./'targetfolder (something)'/ ``` . Aug 15 at 17:03
  • (Part III) Now, as for what @Nmath says, the thing is that after a distribution upgrade (or perhaps it was a fresh install of Ubuntu 20.04, I can't remember now) I was unable to log into user2 (it kept sending me back to the login screen), due apparently to some change in the permissions, the UID and GID of that user. I cannot be sure of all steps, but I think that when I first corrected the permissions and UID, I was able to log in, but it still did no decrypt .Private , ... Aug 15 at 17:06
  • (part IV) .... so, I believe the system at that point created the standard home folders and files as if it were a new user ("outside" of .Private ). I then initially copied a folder with a backup of .Private into /home/user2, but later, after correcting the GID as well, it finally decrypted .Private at login and I had access to the original contents of /home/user2 . Aug 15 at 17:09

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.