Impossible de supprimer le journal d'erreurs ~ 750G produit après la modification de l'autorisation pour / usr / bin / (Sudo non autorisé)
Problème: Après plusieurs heures à enquêter sur la raison qui a mangé mon espace disque et l'a amené à zéro, je me suis dit que c'était dû à la modification de l'autorisation à la racine répertoire (je ne me souviens pas du nom exact du répertoire racine). Je me souviens avoir renommé un fichier dans un répertoire racine en modifiant l'autorisation de manière récursive à l'aide de chmod -R option (pour /usr/bin/ répertoire). J'ai trouvé le fichier qui a mangé mon espace en utilisant la réponse this , qui montrait ce qui suit:
631G dans /var/log/cups/error_log.1, et
110G dans /var/log/cups/error_log
En raison de l'espace disque nul, je ne peux pas redémarrer, donc je ne peux pas me connecter au système, sauf pour la récupération. Ce problème est quelque peu similaire à la suggestion this , sauf que je ne peux pas implémenter cette suggestion par manque de privilèges Sudo, qui est probablement lié aux autorisations.
Question: J'ai essayé de supprimer les fichiers journaux d'erreurs ci-dessus, mais cela ne sera pas autorisé car ma commande Sudo a été vissée. Je crois que ce problème est lié au problème d'autorisation non sécurisée qui a entraîné la formation d'un fichier journal décrit ci-dessus. L'erreur qui m'empêche d'utiliser Sudo est la suivante: /usr/bin/Sudo must be owned by uid 0 and have the setuid bit set
J'ai essayé quelques suggestions pour restaurer les privilèges Sudo (par exemple this , this , et this ), mais cela n'a pas aidé ... en gros , il ne peut pas implémenter ceux suggérant que l'opération n'est pas autorisée. J'utilise le terminal via Alt+F2 mode lorsque j'essaye de redémarrer.
Je voudrais supprimer ce journal d'erreurs et pouvoir réutiliser mon système normalement sans aucun problème.
J'ai fait quelques recherches sur plusieurs heures et cela montre deux approches
Approche 1 : Bien que cette question avec un problème similaire donne quelques suggestions, par exemple pour arrêter le cups, supprimez le fichier journal, etc., mais ceux-ci ne fonctionnent pas pour moi comme je l'ai expliqué plus tôt car mon Sudo ne fonctionne pas.
Approche 2 : Ce problème est survenu après que j'ai changé l'autorisation en /usr/bin/ répertoire, il peut donc être nécessaire de rétablir les autorisations. Cette question est sur une ligne similaire, mais je ne peux pas dire si la réponse est utile.
ÉDITER
J'ai supprimé le gros fichier du shell racine en mode de récupération et j'ai essayé d'arrêter les tasses en utilisant la suggestion de l'approche 1 afin que le fichier journal des erreurs n'augmente pas à nouveau. Je l'ai fait car aucune des commandes suggérées par les réponses ne pouvait aider à rétablir les autorisations, donc lorsque je me suis connecté au système d'exploitation, le fichier journal des erreurs a commencé à augmenter. Pour cette raison, j'ai dû arrêter à nouveau les tasses du mode de récupération. Cependant, après avoir fait ces choses, je ne suis toujours pas en mesure d'accéder au Sudo et j'obtiens la même erreur que celle décrite ci-dessus dans la question. Un problème est résolu, qui consiste à supprimer le fichier qui a consommé mon espace, mais l'autre problème important de revenir en arrière les autorisations n'est pas résolu. De plus, une fois que j'ai redémarré les tasses, la taille du fichier augmente à nouveau (déjà 3,5 G en quelques minutes) avec les commandes suivantes:
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
Voici ma sortie de $ 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
Eh bien, la "solution" ne devrait pas être trop mauvaise.
Démarrez un lecteur/CD Flash en direct ou en mode de récupération et supprimez les gros fichiers journaux.
Pour supprimer des fichiers, vous devez remonter le système de fichiers racine rw
mount -o remount,rw /Pour plus de détails, voir https://wiki.ubuntu.com/RecoveryMode
Si vous avez utilisé un redémarrage Flash/USB en direct pour le mode de récupération maintenant. Si vous êtes déjà en mode de récupération, continuez avec
apt-get --reinstall install \`dpkg --get-selections | grep install | grep -v deinstall | cut -f1\`Pour plus de détails, voir
http://hyperlogos.org/page/Restoring-Permissions-Debian-System
Pour essayer de restaurer votre système dans un état semi-fonctionnel ...
Si cela ne fonctionne pas, vous devrez peut-être simplement réinstaller Ubuntu ...
- démarrer dans le menu GRUB
- choisissez Options avancées
- choisissez le mode de récupération
- choisissez l'accès root
- à l'invite #
type:
mount -o rw,remount / # pour remonter le disque en r/w
rm -i /var/log/cups/error_log # supprimer le gros fichier journal
rm -i /var/log/cups/error_log.1 # supprimer le gros fichier journal
chmod -R 755 /usr/bin # essayez de remettre/usr/bin à quelque chose de proche de la normale
chmod u+s /usr/bin/Sudo # setuid sur la commande Sudo
chown root:root /usr/bin/Sudo # juste au cas où ça gâcherait aussi
reboot # redémarrez l'ordinateur
Mise à jour # 1:
Il est temps de réinstaller Ubunt. Vous avez apporté plus de modifications à votre système que nous ne le savions, et le réparer à la pièce ne fonctionnera tout simplement pas. Décochez la case format et il conservera votre répertoire/home actuel.
Je suis confronté au même problème pour Ubuntu 16.04 après avoir modifié les autorisations de l'équipe. Il y a quelque temps, j'ai réussi à avoir des privilèges root via le terminal après avoir lancé le mode de récupération.
Essayez de taper Sudo su ou su, puis nautilus. Avec ces autorisations, vous pouvez supprimer ces fichiers. Mais, comme vous, je n'ai pas compris l'augmentation constante de Go dans l'ordinateur portable. Pour moi, semble augmenter de 100 Go après 1 heure d'utilisation.
Je sais que ce n'est pas une bonne réponse, mais je n'ai pas assez de points pour répondre à d'autres réponses.
Soit dit en passant, s'il existe une solution pour arrêter l'augmentation des fichiers error_log, faites-le moi savoir. La façon la plus simple est de réinstaller ubuntu, mais ce n'est pas l'idée.
Cordialement