backup folder is inaccessible

Hi

Thank you for your bug report.
could you please tell me the version of sbackup you use.

Hint (Use this command to know it):
dpkg-query -s sbackup

wattazoum

Hi,

version is 0.10.3-0.2.

After a scheduled backup the folder keeps retaining those permission. If I reboot the system, the folder permissions go back to 777.

Hi,

I don't think it's a problem actually. Since Sbackup is actually only
usable by root, it's been decided that the only on that should be able
to have access to the backup snapshot should be him. That's why the
backup dir is closed.
Then since VFAT doesn't handle permissions well, after you rebooted
the mounting options behaviour has been kept.

I understand this, but maybe a permission to all "admin" group users would have been better. As I am used to have a look at the backup dir and browse into the tgz files, I would like to use nautilus but I prefere not to open nautilus from root.

Fixed upstream. If you're interested in testing it please use that link : https://bugs.launchpad.net/ubuntu/+source/sbackup/+bug/102577/comments/12

Please confirm that it's what you wanted.

Thank you, it seems to fix the problem. Just one issue: the file flist is not inheriting the permissions and it is the only inaccessible one with straight root permissions.

yeah ,

I saw that one. I'll try to get it fixed :-)

This one fixes it. Please upgrade you version, cause in the version you have, there is on big bug .

Thanks for the notification. I hope the Debian packagers will remember to change id 117 to something appropriate, as on my Debian Etch system here the id 117 is the "powerdev" group :-)
Are these Group IDs guaranteed to be the same on all Ubuntu installations (also after dist-upgrade and whatnot)?

On my Ubuntu Feisty powerdev is 123 and admin is 124!

Bug #113220 : I have opened that bug after I noticed this difference. I'll try to get the gid by the name of the group by still ... This is something to think about.

Hi ,

i used the *grp* module of python to get the admin GID so normally the issue should be fixed.

Since Fabio and Oliver have a different GID for the admin group. it makes them good candidates for testing :-p . ( just kidding ;-) )

Could you please test it (so that we get rid of this bug :-) ) ?

With v. 0.10.4beta5 the file flist is still not accessibile to anyone but root.

Is there any special procedure to perform in order to test the new version (other than waiting for tomorro'w anacron?)

no, just launch :

sudo sbackupd

from the terminal

Tested with new version, same behaviour. The flist is owned and accessible only to root.
But this is not a great problem, as the other files can be accessed.

oki,

But you were saying that your admin GID was 124, and in the version
beta5 I was using GID 117 so the backup shouldn't belong to the admin
group , is it ?

Then in the beta6, I use a new function to get the admin GID, so now
your new backups should belong to group 124. Can you confirm ?

No, I can't. As I told you I am saving backups on a VFAT partition, so each file has root:root ownership.

oh, sorry for that . Well, I'll assume it works (as it does for me)

I'll work on the flist file