I was trying to do:-

 

chmod -R 777 ./

 

But, I forgot the period and I accidentally ran it on "/", also, because of the fact I was using shellinabox ctrl+c didn't work, so, I had to use the "powerdown" command to get it to stop. I've yet to turn it on (Will be trying to using IPMI/WakeOnLan packets, I just wanted to post this first) and I'm logging into my PC via RDP.

 

What's the worse this can do (Probably a lot) and what's the best thing to do remotely to fix this? I have access to a windows machine which is on LAN.

 

EDIT:- It ran for ~ 30 seconds, I doubt it got to /mnt assuming it was in alphabetical order, and, even if it did, what would really matter if it ran against that? If worse comes to the worse and I can't fix it remotely, will I be able to just copy /config/ off the drive, reformat the drive, stick /config/ & my licence back and run it as if I hadn't cocked it up big time?

 

EDIT2:- Replying to pings, normally it only replies to pings post-boot, so, hopefully that means hope. Normally it starts sending me "Turning on" emails ~ 5 minutes after it starts replying to pings /fingersCrossed

 

EDIT3:- Just sent me my first (out of three) boot emails, this happens at the top of my go script directly after the http UI and unmenu, least now I know it turns on, but, is there anything I should do about the fact that now a couple thousand files have 777 as their permission?

I suspect you may largely get away with this!

 

The main Linux file system will not be affected as this is loaded fresh each time the system boots.

 

Your flash drive (/boot) uses a FAT based file system that does not support access permissions so this is unlikely to be a problem.

 

The issue comes down to files on your shares.  If you are using the 5.0RC11 release then the 'newperms' command can be run to set all files back to their normal default permissions and access rights. If you have requirements over and beyond this then I am not sure of the best way to proceed.

I suspect you may largely get away with this!

 

The main Linux file system will not be affected as this is loaded fresh each time the system boots.

 

Your flash drive (/boot) uses a FAT based file system that does not support access permissions so this is unlikely to be a problem.

 

The issue comes down to files on your shares.  If you are using the 5.0RC11 release then the 'newperms' command can be run to set all files back to their normal default permissions and access rights. If you have requirements over and beyond this then I am not sure of the best way to proceed.

 

Testing my share (Not all files, obviously) for a bit, all files seem to sill have the correct permissions (Although, I only tested my cache drive because that's the drive that has all the plugins/etc, all my other files are just default "newperms" which shouldn't really be too hard to reset assuming their permissions are broken).

 

However, my main concern was the flash drive itself, and you say that it doesn't support permissions, so, hopefully I got off Scott-free.