On Fri, 2010-10-08 at 19:48 +0200, Sven Joachim wrote:
> On 2010-10-08 18:58 +0200, Xavier Bestel wrote:
>
> > On Fri, 2010-10-08 at 18:45 +0200, Sven Joachim wrote:
> >> Interesting, chown(2) does not mention EINVAL as a possible error code.
> >> I'm not familiar with cifs, can you chown other files on the remote
> >> drive?
> >
> > No, I can't chown anything on the drive.
> > I don't really know why that is. The underlying filesystem (it's on a
> > D-Link DNS-323, a small linux appliance) is ext3, so it supports
> > uids/gids. Albeit the SMB user isn't administrator on the machine, so I
> > guess that's why it can't chown.
>
> That sounds plausible.
>
> > I changed the BM_REPOSITORY_SECURE option to "false" to avoid BM doing
> > the chown, and now it should work. I'll wait for the crontab to fire
> > tonight, and for the backup to complete (>24h) to check.
>
> Setting BM_REPOSITORY_SECURE to false should do the trick, please report
> back whether the backup succeeds.
Worked nice, thanks.
Although the tarring itself spent 26 hrs, then another 10 hrs for the
md5sums.
What's annoy me a bit is that the master tarball is nearly 500G, and the
incremental one, with only very few changes (a few megabytes) weights
100G ! Apparently it's full of empty directories which take up space for
nothing.
Thanks,
Xav
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
