Error 1? Final moment permissions problem on target?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Error 1? Final moment permissions problem on target?

Ron Leach
List, good morning,

We're in the middle of moving our backup destination from an old
machine (with only 2TB) to a new one with 6TB space; each of these is
on a separate NFS share mounted under /mnt.  Our migration scheme is
straightforward, but we hit a problem, possibly with permissions, and
I don't understand what to do.

Migration steps:

(1) Halt the regular rdiff-backups, by commenting out the invocations
in crontab

(2) Using the same user as the user who runs the rdiff-backups, copy
the existing target repository onto the new destination server;
$ cd /mnt/exist-dest
$ cp -a -u -v .* -t/mnt/new-dest

(3) Execute rdiff-backup using the new machine as the destination
$ rdiff-backup --print-statistics -v3 --exclude /Source/.Trash-1000
/Source /mnt/new-dest

(4) Check the log/report and, if ok, restore the automatic cron
invocations, edited to backup to the new destination.


We hit a problem, though, and I don't understand what to do to fix it.

Step 2 reported an error when the cp command finished:
cp: preserving times for `/mnt/new-dest/.': Operation not permitted

The files had all 'seemed' to copy across ok, so I went ahead with
step 3.  But step 3 failed also, at what was close to its final step
(judging by the sequence of the timestamps on the various directories
and files in the new destination):

Exception '[Errno 1] Operation not permitted: '/mnt/new-dest'' raised
of class '<type 'exceptions.OSError'>':

The calling tree seems to indicate a permissions cause:
[ ..... ]
File "/var/lib/python-support/python2.5/rdiff_backup/rpath.py", line
927, in chmod
     self.conn.os.chmod(self.path, permissions & Globals.permission_mask)

called from:
[ ....... ]
File "/var/lib/python-support/python2.5/rdiff_backup/backup.py", line
664, in end_process
     rpath.copy_attribs(self.dir_update, self.base_rp)
File "/var/lib/python-support/python2.5/rdiff_backup/rpath.py", line
189, in copy_attribs
     rpout.chmod(rpin.getperms())
File "/var/lib/python-support/python2.5/rdiff_backup/rpath.py", line
927, in chmod
     self.conn.os.chmod(self.path, permissions & Globals.permission_mask)

OSError: [Errno 1] Operation not permitted: '/mnt/new-dest'


I am sure I've set something up incorrectly on the new destination,
but the user can read and write to it so I am not sure why there might
be a problem.  I'd also tried to make sure that the new-destination
had the same permissions as the old-destination.  Two questions I
would like to ask are what is the significance of the error that cp
reported?  And what permissions 'ought' to exist on the rdiff-backup
destination?

I'd be grateful for any comments.  I am not confident about
permissions, in general, so even very basic remarks would be very welcome.

regards, Ron

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Error 1? Final moment permissions problem on target?

Claus-Justus Heine
Could it be that perhaps the UID mapping is not set up correctly? Being
able to do r/w but not being able to preserve times and set permission
could indicate that somehow the NFS-Server "thinks" that the files are
not owned by the user issuing the command. Cam you do a "chmod"
manually? Or can it perhaps be that only the mount-directory
/mnt/new-dest is not owned by the backup user (the chmod error message
of rdiff-backup only mentions the mount-point)?

(BTW, perhaps it would be more efficient to run rdiff-backup through a
remote-shell instead of going through the NFS file system; however, the
setup would be slightly more complicated)

Best,

Claus


Am 15.04.14 11:00, schrieb Ron Leach:

> List, good morning,
>
> We're in the middle of moving our backup destination from an old machine
> (with only 2TB) to a new one with 6TB space; each of these is on a
> separate NFS share mounted under /mnt.  Our migration scheme is
> straightforward, but we hit a problem, possibly with permissions, and I
> don't understand what to do.
>
> Migration steps:
>
> (1) Halt the regular rdiff-backups, by commenting out the invocations in
> crontab
>
> (2) Using the same user as the user who runs the rdiff-backups, copy the
> existing target repository onto the new destination server;
> $ cd /mnt/exist-dest
> $ cp -a -u -v .* -t/mnt/new-dest
>
> (3) Execute rdiff-backup using the new machine as the destination
> $ rdiff-backup --print-statistics -v3 --exclude /Source/.Trash-1000
> /Source /mnt/new-dest
>
> (4) Check the log/report and, if ok, restore the automatic cron
> invocations, edited to backup to the new destination.
>
>
> We hit a problem, though, and I don't understand what to do to fix it.
>
> Step 2 reported an error when the cp command finished:
> cp: preserving times for `/mnt/new-dest/.': Operation not permitted
>
> The files had all 'seemed' to copy across ok, so I went ahead with step
> 3.  But step 3 failed also, at what was close to its final step (judging
> by the sequence of the timestamps on the various directories and files
> in the new destination):
>
> Exception '[Errno 1] Operation not permitted: '/mnt/new-dest'' raised of
> class '<type 'exceptions.OSError'>':
>
> The calling tree seems to indicate a permissions cause:
> [ ..... ]
> File "/var/lib/python-support/python2.5/rdiff_backup/rpath.py", line
> 927, in chmod
>     self.conn.os.chmod(self.path, permissions & Globals.permission_mask)
>
> called from:
> [ ....... ]
> File "/var/lib/python-support/python2.5/rdiff_backup/backup.py", line
> 664, in end_process
>     rpath.copy_attribs(self.dir_update, self.base_rp)
> File "/var/lib/python-support/python2.5/rdiff_backup/rpath.py", line
> 189, in copy_attribs
>     rpout.chmod(rpin.getperms())
> File "/var/lib/python-support/python2.5/rdiff_backup/rpath.py", line
> 927, in chmod
>     self.conn.os.chmod(self.path, permissions & Globals.permission_mask)
>
> OSError: [Errno 1] Operation not permitted: '/mnt/new-dest'
>
>
> I am sure I've set something up incorrectly on the new destination, but
> the user can read and write to it so I am not sure why there might be a
> problem.  I'd also tried to make sure that the new-destination had the
> same permissions as the old-destination.  Two questions I would like to
> ask are what is the significance of the error that cp reported?  And
> what permissions 'ought' to exist on the rdiff-backup destination?
>
> I'd be grateful for any comments.  I am not confident about permissions,
> in general, so even very basic remarks would be very welcome.
>
> regards, Ron
>
> _______________________________________________
> rdiff-backup-users mailing list at [hidden email]
> https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> Wiki URL:
> http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki


-- Claus-Justus Heine [hidden email]
http://http://www.claus-justus-heine.de/

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Error 1? Final moment permissions problem on target?

Ron Leach
On 15/04/2014 10:38, Claus-Justus Heine wrote:
> Could it be that perhaps the UID mapping is not set up correctly? Being
> able to do r/w but not being able to preserve times and set permission
> could indicate that somehow the NFS-Server "thinks" that the files are
> not owned by the user issuing the command. Cam you do a "chmod"
> manually? Or can it perhaps be that only the mount-directory
> /mnt/new-dest is not owned by the backup user (the chmod error message
> of rdiff-backup only mentions the mount-point)?
>

Useful pointers, thank you.  What I find is that all the *directories*
under /mnt/exist-dest and /mnt/new-dest have the same permissions
(exactly as I had intended by using the -a parameter on the cp command
to copy the existing backups to the new machine), but the mount
points, indeed, do differ in owner and group.  Both mount points have
permissions 40777 (shown by mc), so that any user can read and write.

In detail, the mount point of the existing backup /mnt/exist-dest has
owner ron, group users, permissions 40777.

The mount point of the new backup /mnt/new-dest has owner root, group
root, permissions 40777.

An obvious next step is to change the ownership of /mnt/new-dest to be
ron, users, with permissions 40777 (and so match the exist-dest).
Apologies for appearing over-cautious but is there any reason why I
should not just go ahead and do that?

If so, I'll then ask rdiff-backup to check the destination which,
hopefully, will revert this backup attempt, and try again with the
backup.  Actually, I'll first redo the cp command to try and have it
finish without its error, as well, we need to be able to rely on the
integrity of the backups we already have and if there is something not
set correctly, restores later might go awry.

Claus, thank you for the suggestion about the mount point.  (I was
aware that NFS leads to sub-optimal performance but it was simpler to
set up, as you mention.)

regards, Ron

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Error 1? Final moment permissions problem on target?

Claus-Justus Heine
Am 15.04.14 13:27, schrieb Ron Leach:> Useful pointers, thank you.  What
I find is that all the *directories*

> under /mnt/exist-dest and /mnt/new-dest have the same permissions
> (exactly as I had intended by using the -a parameter on the cp command
> to copy the existing backups to the new machine), but the mount points,
> indeed, do differ in owner and group.  Both mount points have
> permissions 40777 (shown by mc), so that any user can read and write.
>
> In detail, the mount point of the existing backup /mnt/exist-dest has
> owner ron, group users, permissions 40777.
>
> The mount point of the new backup /mnt/new-dest has owner root, group
> root, permissions 40777.

Personally, I would probably stick to the mount point owned by root,
would not give "tmp"-permissions to it but instead would create a
subdirectory for the backup below the mount-point. At least the default
ownership of the NFS-mounted volume should be owner of that directory on
the remote machine (from memory, could be wrong in this point). So maybe
one point could be to chown the matching directory of "/mnt/new-dest" on
the hosting server (s.t. it would be owned by the backup user). So you
probably need to change the ownership on the machine hosting the real
hard-disk (AFAIK).

Best,

Claus


--
Claus-Justus Heine                      [hidden email]

http://http://www.claus-justus-heine.de/

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki