0

Recently I executed command chmod -R 666 /, instead of putting directory for the command, after I realised what I did I did CTRL + Z asap, but some necessary permissions from root user were negated, which led to my VPS to not work after restart.

I'm hosting my VPS from ovh.com (https://www.ovh.com/us/g920.rescue_mode), and that should allow me to fix my permissions problems, however, I have no idea what commands to use, as I'm not professional when it comes to this.

PS: This is really necessary for me and I don't want to reset my VPS because it has an entire TS3 server and +10 websites, databases.

Improve this question
1
  • 1
    Do you have any access to the shell or files of the VPS at this point?
    – music2myear
    Apr 19, 2017 at 23:29

2 Answers 2

Reset to default
2

I hate to be that guy but there's no real way to fix this.

You've essentially set the entire system to read/write so things that need to execute cannot be executed including the commands that let you set permissions.

So to fix this - you'd need to boot into a working environment and fix the permissions of every single file. This seems to be the correct link for getting a VPS.

The first step I would take if SSH works is to connect to the server and download everything over sftp or rsync (I've used cyberduck on windows for such a thing). There's also a mention of a '- carry out a backup or data restoration` option I'd check. BACKUP BEFORE YOU DO ANYTHING ELSE. I'm also assuming that there is some flavour of recovery environment independent of your broken system.

Now I'd try to fix permissions. This AU question suggests chmod 0755 would work. Try it, test, and make database dumps.

Reinstall, restore your database dumps and data and back up before you do anything like this.

Improve this answer
1
  • Rather than a global 0755 (which is a terrible idea, because it also removes the setuid bit, which will break sudo and su amongst other things), you're better off trying to clone permissions either from a backup or from a working system. Or at the very least using 755 so you don't wipe the (hopefully still correct) setuid/setgid/sticky bits.
    – Bob
    Apr 20, 2017 at 1:10
1

It's been said that there's really no proper fix for this, but it's almost doable given a rescue environment.

As with all recovery operations, you should do what you can to make sure you have a backup copy, or make one now out of all the data you can access, in case you accidentally do further damage.

First, if you have a recent backup, you might be better off restoring from the backup. Even if you don't want to restore the files (maybe some have been updated since), doing a permission-only restore is a feasible option and reasonably safe - if you haven't installed anything new or changed any configs since, you'd have a clean restore + data changes since.

To do this from a backup, you'd want to first restore the backup to a temp directory, and then copy the permissions over.

The other option is to set up a simple base system (maybe temporarily spin up a new VPS), back up the permissions from there, and restore those permissions to the existing server. However, this will obviously not include any changes from packages you've installed since, nor any config changes you've made. This will probably get you back into a bootable system, but you should not continue using it - plan a full rebuild ASAP.

The general method for backing up, restoring, or copying permissions is to use the getfacl and setfacl commands.

First, cd into the root of the affected system (either / on a running one, or wherever you've mounted the drive on a rescue system, or the temp directory you want to copy permissions from), and then:

Backup with

getfacl -R . >permissions.facl

and restore with

setfacl --restore=permissions.facl
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .