>> root@Tesistas:/home/tesistas# ls -la /var/spool/cron/crontabs/ >> total 12 drwx-wx--T 2 root root 4096 jul 10 01:00 . >> drwxr-xr-x 5 root root 4096 abr 17 16:01 .. >> -rw------- 1 tesistas crontab 1630 jul 10 01:00 tesistas > > Parece correcto. Sube un nivel más para ver si los permisos/propietarios > siguen bien: > > ls -la /var/spool/cron/ >
-------------------------------------------------------------------------- tesistas@Tesistas:~$ ls -la /var/spool/cron/ total 20 drwxr-xr-x 5 root root 4096 abr 17 16:01 . drwxr-xr-x 4 root root 4096 jul 18 14:52 .. drwxrwx--T 2 root root 4096 abr 17 16:03 atjobs drwxrwx--T 2 root root 4096 oct 3 2014 atspool drwx-wx--T 2 root root 4096 jul 10 01:00 crontabs ----------------------------------------------------------------------------- > Y revisa también lo que comentan en esta página, más que nada porque el > mensaje que recibe el usuario parece el mismo que recibes tú: > > crontab listing or editing results in fopen: permission denied > http://serverfault.com/questions/619296/crontab-listing-or-editing- > results-in-fopen-permission-denied > Revisé el link que dejaste, y efectivamente puedo editar el crontab de mi usuario accediendo como superusuario, sin modificar permisos: ------------------------------------------------------------------------------------- tesistas@Tesistas:~$ sudo crontab -u tesistas -e 0 0 13 * * 4 /usr/bin/freshclam --quiet; /usr/bin/clamscan -ril /home/tesistas/Descargas ------------------------------------------------------------------------------------- Aunque lo extraño es que antes podía hacerlo sin sudo. Además, creo que el enfoque no es tanto sobre cron/crontab, sino en ¿por qué carrizo se vieron afectados los permisos si no los toqueteé? y ¿por qué no me deja apagar/reiniciar el equipo, devolviéndome al inicio de sesión, aún como superusuario? >> Aquí si es falta mía en agregar que para apagar el ordenador desde el >> usuario normal sin privilegios de root (es un ordenador con un solo >> usuario -tesistas-, pero utilizado por varias personas desde la misma >> cuenta de usuario), había creado links simbólicos de los comandos >> /sbin/shutdown, /sbin/reboot y /sbin/halt al path del usuario tesistas. >> Esto en nada representa un factor que contribuya al problema en debate, >> puesto que lo había implementado ya desde hace más de año y medio, y >> funcionaba de maravilla. > > Pero no es normal que no te permita apagar el equipo y que te devuelva l > inicio de sesión, porque entiendo que has ejecutado el "shutdown -h now" > como súperusaurio ¿no? En caso contrario, prueba como root. > Si, lo he intentado como root > Bueno, es pronto para saber qué es lo que ha pasado, de momento hay > algunos comandos que no funcionan como deberían pero de ahí a echar la > culpa a los backports va un mundo :-) > > Los paquetes de los backports llevan la coletilla "-bpo" y aquí la > mayoría (en realidad, todos menos el kernel) no la tienen, es decir, que > no parece que el problema venga de esos paquetes. > Si lees mi mensaje anterior en el hilo (de fecha 10 de octubre de 2015, 2:28 a. m), te darás cuenta por qué lo digo. Saludos fdm
