Ubuntu

/var/backup unreadable and huge

Asked by Stephen Toney

I installed Sbackup and let it backup automatically. It ate up about 10GB a day. I've uninstalled it, but now can't reclaim the space. /var/backup is marked "unreadable" and I can't get into it to delete whatever files may be there. I've tried both the Gnome File Browser and "sudo cd /var/backup" from the Terminal. No info on this found by Googling. (Actually I won't know until tomorrow whether Sbackup was the culprit, but I still need to get into that directory.) Many thanks in advance for any newbie help!

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
Philip Paquette
Solved:
Last query:
Last reply:
Revision history for this message
Philip Paquette (pcpaquette) said : 		#1

Can't you just 'sudo rm -R /var/backup' ?

Revision history for this message
Stephen Toney (toney) said : 		#2

Thanks, Philip, that worked. Sorry for not knowing that.

However, inquiring minds still want to know:
- What does it mean when a directory is "unreadable"?
- Why didn't "cd /var/backup" work?
- Why did File Manager show 0 files when there were 25 Gigabytes of stuff in there?
- (And a side issue: why doesn't Disk Manager refresh the amount of free-space after a deletion? I had to restart it to see the new free-space.)

Thanks again!

Revision history for this message
Best Philip Paquette (pcpaquette) said : 		#3

Hi, if I remember correctly, Sbackup created the backup as root in /var/backup... The folder has permissions 700 with owner root/root.. That means that root can read/write/exec (7), but other users don't have any access at all, not even read (0)... So the directory is unreadable to the normal user... Also, 'cd /var/backup/' works, but you can't issue it with a sudo command directly... you need to open a root terminal by typing 'sudo -s' -> sudo me a shell (a terminal) and then cd /var/backup as root ... File Manager couldn't read the stuff in there because the normal user couldn't access the directory... and for the side issue, I remember having a similar problem once, I think the behaviour is because of journaling filesystem, but I don't remember the exact reason...

Also, could you mark this question as solved....

Thank you...

Revision history for this message
Stephen Toney (toney) said : 		#4

Philip, Thanks for the helpful information!

Stephen