[Klug-general] Permissions problem

[Michael E. Rentell]

That looks an interesting solution to the problem Alan. Thanks for that, 
and also for spelling it out in such detail. Much appreciated.
Yesterday I managed to follow the advice from another in the group who 
suggested mounting the remote backup directory in my user directory and 
then copying each directory selected for backup to it. That worked and I 
was thinking of typing that out to a script today. That sort of thing is 
quite an adventure for me so I'll probably try that first.
Such nice folk in this group. Many thanks to all.
MikeR


On 15/12/11 17:40, Alan Buchel wrote:
> Yes, reliably mounting destination storage with correct permission is 
> always an issue for backups, and full OS recovery can be a mare 
> therefrom. Instead you can use an ssh destination in rsync and this 
> bypasses the issue altogether:
>
> 1) create a file called /file.exceptions, in there list all the 
> directories you do NOT want ot include in the backup. An example will 
> be #file.exceptions.example:
>
> /dev
> /media
> /mnt
> /home/dummyuser_that_dont_need_backup
> /home/phileas/.Trash
>
> 2) say your machine with backup file storage is on 192.168.1.2 then 
> from a root cli on source you can run rsync like this:
> ( achieve this using "sudo su -")
>
> rsync -azv  / root at 192.168.1.2:/backupsdirectory  
> --exclude-from=/file.exceptions
>
> -a maintains subdirs, ownership & permissions
> -z compresses over network
> -v verbose
>
> If your using some distros you will first need to give root a 
> password. Or you can use ssh keys, also necessary if you want to cron 
> this job. To do that, create a password-less keypair (with 
> ssh-keygen), call them for example private.key and public.key. Put the 
> public.key into .ssh/authorized_keys on destination machine, the 
> private into /root/ on source machine and run the rsync as follows:
>
> rsync -azv -e "ssh -i /root/private.key" / 
> root at 192.168.1.2:/backupsdirectory  --exclude-from=/file.exceptions 
> --log-file /var/log/backup.log
>
> Alan
>
> On 15/12/11 12:29, Michael E. Rentell wrote:
>> On 15/12/11 11:41, Mike Evans wrote:
>>> Sorry to come to this late.
>>>
>>> If you are using NFS to mount the drive then it will work provided 
>>> your user ID numbers are the same on each machine as that's what NFS 
>>> uses. (Hopelessly insecure but hey they assume that you know what 
>>> you're doing and can secure your network properly.)  However there 
>>> is an exception to this:  root is protected and the default 
>>> behaviour is to do what's called 'rootsquash' - which stops root on 
>>> one machine being root on another.  There is some setting you can 
>>> change to open that hole too if you really need to.
>>>
>>> MikeE
>>>
>> I suspect that I am using samba because the cli line I use to connect 
>> is:
>>
>> mount -t cifs //192.168.2.4/Backups /mnt/backups -o 
>> username=mick,password=mick
>>
>> That connects no problem when using sudo from the cli. I can read all 
>> the files there and copy them back individually to my main machine. 
>> But if I try to copy to it, I normally use nautilus, stuff from the 
>> main machine to the mounted directory it is forbidden.
>>
>> When I sudo grsync (I find rsync too intimidating with all those 
>> baffling parameters) it whips through all the files to send and about 
>> a quarter of them are shown in red with permission denied error 13. 
>> All the rest show up in black and you would think they are going over 
>> OK. But when I check on the backup machine none have been updated - 
>> even if I tell nautilus to refresh the list just in case it's missed 
>> something.
>>
>> The backup machine uses PCLinuxOS so I can use its very useful admin 
>> tools to check the samba shares and the backup file has the password 
>> for mick set and its read/write permissions set. When I cli ls -l 
>> that backup directory all the directories are drwxrwxrwx and all the 
>> files in them are rwxrwxrwx.
>>
>> So I have no backup facility now.
>>
>> I've looked at other backup solutions but they all seem to produce an 
>> archive file which can only be restored in full. I need a backup from 
>> which I can retrieve a single file if needed.
>>
>> Still baffled - sorry folks. No doubt I'm still a bear of very little 
>> brain. But I do appreciate all the suggestions I've received over the 
>> past 24 hours. Everyone seems to be bending their minds to my 
>> problem. No doubt it is a trivial thing, but it's beyond my minimal 
>> capabilities at the moment.
>> MikeR
>>
>>
>> _______________________________________________
>> Kent mailing list
>> Kent at mailman.lug.org.uk
>> https://mailman.lug.org.uk/mailman/listinfo/kent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/kent/attachments/20111216/d7b932b4/attachment.htm>