Can't delete ~750G error log produced after changing permission for /usr/bin/ (sudo not permitted)

Issue: After several hours investigating the reason that ate my disk space and brought it to zero, I figured that it was due to changing the permission in the root directory (I can't recall the exact name of the root directory). I remember renaming a file in a root directory by changing the permission recursively using chmod -R option (for /usr/bin/ directory). I found the file that ate my space using this answer, which showed following:

631G in /var/log/cups/error_log.1, and

110G in /var/log/cups/error_log

Because of zero disk space, I cannot reboot, so I cannot login into the system except for recovery. This problem is somewhat similar to this suggestion, except that I cannot implement that suggestion for lack of sudo privileges, which is probably related to permissions.

Question: I tried deleting the above error log files, but it won't allow because my sudo command has been screwed up. I believe this issue is related to the insecure permission issue that resulted in forming a log file discussed above. The error that stops me from using sudo says the following: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

I have tried some suggestions to restore sudo privileges (e.g. this, this, and this), but it didn't help...basically, it can't implement those suggesting that operation is not permitted. I am using the terminal through Alt+F2 mode when I try to reboot.

I would like to delete that error log and be able to use my system normally again without any issues.

I did some search over several hours and it shows two approaches

Approach 1: Although this question with similar problem provides some suggestions, for e.g. to stop the cups, delete the log file, etc., but those are not working for me as I explained earlier because my sudo is not working.

Approach 2: This problem occured after I changed the permission to /usr/bin/ directory, so it may need reverting back the permissions. This question is on a similar line, but I can't say whether the answer is useful.

EDIT

I have deleted the large file from root shell in recovery mode, and tried stopping the cups using the suggestion from approach 1 so the error log file does not increase in size again. I did that because none of the commands suggested by the answers could help revert the permissions, so when I logged into the OS, the error log file started to increase. Because of this I had to stop the cups from reocvery mode again. However, after doing these things I am still not able to access the sudo, and I get the same error as described above in the question. One issue is solved, which is deleting the file that ate up my space, but the other important problem of reverting back the permissions is not resolved. Also, once I restarted the cups, the file is increasing in size again (already 3.5 G in few min) with following commands:

W [05/Sep/2017:05:10:42 -0400] Notifier for subscription 2 (dbus://) went away, retrying!
E [05/Sep/2017:05:10:42 -0400] File \"/usr/lib/cups/notifier/dbus\" has insecure permissions (0100755/uid=1000/gid=1000).
W [05/Sep/2017:05:10:42 -0400] Notifier for subscription 2 (dbus://) went away, retrying!
E [05/Sep/2017:05:10:42 -0400] File \"/usr/lib/cups/notifier/dbus\" has insecure permissions (0100755/uid=1000/gid=1000).
W [05/Sep/2017:05:10:42 -0400] Notifier for subscription 2 (dbus://) went away, retrying!
E [05/Sep/2017:05:10:42 -0400] File \"/usr/lib/cups/notifier/dbus\" has insecure permissions (0100755/uid=1000/gid=1000).
W [05/Sep/2017:05:10:42 -0400] Notifier for subscription 2 (dbus://) went away, retrying!


EDIT 2

Following is my output of \$ ls -al /usr/bin/su*

-rwxr-xr-x 1 root root 136808 Jul  4 03:37 /usr/bin/sudo
lrwxrwxrwx 1 root root      4 Jul  4 03:37 /usr/bin/sudoedit -> sudo
-rwxr-xr-x 1 root root  47680 Jul  4 03:37 /usr/bin/sudoreplay
-rwxr-xr-x 1 root root  39672 Mar  2  2017 /usr/bin/sum

• Without sudo powers it would be difficult! – George Udosen Sep 1 '17 at 19:15
• What are the permissions of sudo? ls -la /usr/bin/sudo will tell you, if you want to add the output of that command to this thread. It's hypothetically possible that the lack of disk space is somehow interfering with the sudo command. If you followed this answer as you said and you can successfully get to the root shell, why not try deleting the error logs in question that way, as the root user? – drkokandy Sep 1 '17 at 19:22
• @drkokandy: The output to ls -la /usr/bin/sudo is -rwxr-xr-x 1 user_name user_name 136808 [date and time] /usr/bin/sudo. Regarding you other question, the problem is I can't acess sudo privilege from the terminal that I am able to use...which is not inside the OS; I am accessing it by Alt+F2 once the system starts to boot. Please let me know if you need any clarification to help. – user11 Sep 1 '17 at 21:32
• hmm, that's not what you said you tried. The link you posted & said you tried involved dropping to the actual root prompt, which has now been suggested as another solution. Try the root prompt, rather than the normal unpriviledged terminal, or use the recovery media solution suggested. – drkokandy Sep 4 '17 at 1:40

Well the "solution" should not be too bad.

1. Boot a live Flash drive / CD or to recovery mode and delete the large log files.

To delete files you need to remount the root file system rw

mount -o remount,rw /


For details see https://wiki.ubuntu.com/RecoveryMode

2. If you used a live Flash / USB reboot to recovery mode now. If you are already in recovery mode continue with

apt-get --reinstall install \dpkg --get-selections | grep install | grep -v deinstall | cut -f1\


For details see

http://hyperlogos.org/page/Restoring-Permissions-Debian-System

• What if there were DKMS modules? Or is it only dpkg stuff that need to be reinstalled? – WinEunuuchs2Unix Sep 1 '17 at 19:43
• You would have to manually fix anything installed outside apt (apt-get / dpkg) including DKMS modules, but you would at least have sudo power and your bast system should work. – Panther Sep 1 '17 at 19:47
• @bodhi.zazen This won't work as shown, because you're booted to the Ubuntu Live DVD/USB, and / is not on the hard drive. Recovery mode should fail too because of the permissions on /usr/bin. apt-get should fail too. Maybe chroot then chmod -R /usr/bin on the hard disk? – heynnema Sep 1 '17 at 22:44
• @heynnema wouldn't it be chmod a+r /usr/bin instead? After all it was taking away read permissions with -r that started the fiasco wasn't it? – WinEunuuchs2Unix Sep 2 '17 at 0:04
• @WinEunuuchs2Unix I didn't give a full and proper chmod command, as I figured bodhi.zazen would understand my intent. The -R was for recursive, as the OP originally did. Good catch though! – heynnema Sep 2 '17 at 0:23

To try and recover your system to a semi-workable state...

If this doesn't work, you may just have to reinstall Ubuntu...

• boot to the GRUB menu
• choose Recovery mode
• choose Root access
• at the # prompt

type:

mount -o rw,remount / # to remount the disk as r/w

rm -i /var/log/cups/error_log # delete the large log file

rm -i /var/log/cups/error_log.1 # delete the large log file

chmod -R 755 /usr/bin # try to put /usr/bin back to something close to normal

chmod u+s /usr/bin/sudo # setuid on the sudo command

chown root:root /usr/bin/sudo # just in case this is messed up too

reboot # reboot the computer

Update #1:

Time to reinstall Ubuntu. You've made more changes to your system than we knew about, and fixing it piece-meal just won't work. Uncheck the format box and it'll keep your current /home directory.

• Thanks. I will let you on Tuesday whether this suggestion worked or not. – user11 Sep 3 '17 at 12:34
• The 'chmod' and 'chown' command you suggested didn't revert back to normal permissions. I was able to login, but the same error log files continue increasing in size rapidly, so I had to log out again and go back into the recovery mode to delete them. – user11 Sep 5 '17 at 12:24
• Even while being in the root shell prompt, I can't do sudo service cups stop. It throws the same error about ..must be owned by uid 0. Plus, whenever I try to reboot and enter your suggested commands, the root shell sometimes just disappears and starts loading something...when it returns, it overlaps with the other commands on the screen. – user11 Sep 5 '17 at 12:39
• @user11 Don't try and use sudo in the root recovery shell. Use the commands as I've shown them. Delete the log files again, try systemctl stop cups, and then the remaining commands. Upload pictures of the screen for me to see if you run into trouble. Tell me EXACTLY which commands give you trouble, and the error message. – heynnema Sep 5 '17 at 14:24
• When I log into the OS, sudo does not work even after I implement your commands in the root shell. – user11 Sep 5 '17 at 14:29

I'm facing the same issue for ubuntu 16.04 after changing team permissions. A while ago I managed to have root privileges through terminal after launching recovery mode.

Try typing sudo su or su,and then nautilus. Having those permissions you could delete those files. But, same as you I haven't figured out the constant increasing of GB in the laptop. For me seems to increase 100GB after 1 hour of usage.

I know this isn't a proper answer, but I haven't enough points to reply to other answers.

By the way, if there is a solution to stop the increasing error_log files, let me know. The easiest way is reinstalling ubuntu, but that's not the idea.

Regards