From: Frank Steinmetzger <Warp_7@gmx.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Permission error when trying to rsync over nfs
Date: Sat, 31 May 2025 01:35:55 +0200 [thread overview]
Message-ID: <aDpA27OfMBxDxzMY@q> (raw)
In-Reply-To: <cb44c8cd-e903-d8f9-932d-4e3279091e54@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3912 bytes --]
Am Mon, May 26, 2025 at 05:09:23AM -0500 schrieb Dale:
> Michael wrote:
> > On Monday, 19 May 2025 14:39:21 British Summer Time Dale wrote:
> >> Howdy,
> >>
> >> I'm wanting to move a Data partition over to a new set of drives that
> >> are encrypted. I decided the easiest way to do this is to put the new
> >> drives on the NAS box and mount them like I do when I backup my large
> >> Video directory only copy the Data files instead. So, on the NAS box, I
> >> set up the three drives, 2 16TB and the famous 20TB drive, with LVM and
> >> dm-setup. Once I had that setup, I mounted in just like I would the
> >> Video directory. I also ran exportfs -a so it would see the newly
> >> mounted drive set and make it available. On my main rig, I then mounted
> >> it using the same command I would for the Video directory for backups.
> >> Then I took the same command for backing up my video but just replaced
> >> the source and target with the Data path instead of video. Basically,
> >> everything is set up the same, I just replaced everything with the
> >> drives I want info copied to in both mounting drives and commands.
> >>
> >> This is the error I get.
> >>
> >>
> >> rsync: [generator] recv_generator: mkdir "/mnt/TV_Backup/Data/random
> >> directory" failed: Permission denied (13)
> >>
> >>
> >> I know to run the rsync command as a user, not root.
Just as you should all programs that deal with user data. With rsync, if you
give it a --delete with the wrong destination or so, you can wipe the
system. Or overwrite the wrong files.
> >> I have to do that
> >> when updating my video backups. I recall getting a error, could be this
> >> one, at first but setting something to make it work.
If you copy to an NFS, I don’t quite see how running the writing process (be
it rsync or cp) as root changes the permission situation. Unless the
destination directory is already part of the share and has write perms only
for root.
> > If you want to update the contents of a fs over the network, then rsync is
> > your tool. Why is NFS coming into this at all?
You can use rsync for local copies. In this case, local also means a mounted
NFS share. Plus, if your CPU is as old as in Dale’s NAS, using rsync over
ssh introduces even more overhead for SSH encryption.
> I did some digging. I found some info on rsync to a networked system.
> I switched to that method. This is the command I used.
>
>
> time rsync -uivr --progress /home/dale/Desktop/Data/*
> root@10.0.0.5:/mnt/backup
-i and -v are redundant. While v only shows the processed file, -i adds the
reason to the output.
> My old way did act odd. It would read a lot of data from the main rig,
> transfer across the network and then write to the NAS drive. Then
> repeat. It did not do it in a continuous way tho. It did them one at a
> time. Read a while. Transfer. Then write a while. Repeat. Overall,
> it was kinda slow, ish.
>
> With this new method it is doing it all at the same time in a continuous
> flow but slower.
There is nothing fancy about the command you posted. I, too, observe this
read-write cycle when doing stuff over SSH onto a ZFS share and it annoys me
sometimes. But haven’t had the urge to solve it yet. I don’t transfer huge
volumes of files that often.
What is not very often used in my experience is the -u flag. It causes rsync
to skip all files whose timestamp hasn’t changed. If you don’t use it, maybe
rsync’s detection of unchanged files does not work properly over NFS, hence
it reads and writes all files again. (Just a conjecture on my part.)
--
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.
As long as my boss pretends to pay me adequatly,
I will pretend to work properly.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2025-05-30 23:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 13:39 [gentoo-user] Permission error when trying to rsync over nfs Dale
2025-05-20 11:46 ` Michael
2025-05-20 13:27 ` Dale
2025-05-20 14:02 ` Michael
2025-05-20 16:30 ` Dale
2025-05-21 18:16 ` Michael
2025-05-21 19:42 ` Dale
2025-05-21 20:03 ` Michael
2025-05-26 10:09 ` Dale
2025-05-28 12:58 ` Dale
2025-05-30 23:35 ` Frank Steinmetzger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aDpA27OfMBxDxzMY@q \
--to=warp_7@gmx.de \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox