[unison-users] Linux File/Direcotry Ownership- I can cp a file, but not backup via unison

[Dave [e-mail] [unison-users]]

I have an issue with linux file/directory ownership that is allowing me to copy a file using `cp`, but not back it up via `unison`. The problem appears to be in the change of ownership for a temp file of `unison`'s. I'd like to know how to correct this.

The file is in a directory structure that looks like:

/.../A/B/C/D.txt

Ownership & permissions look like:

A is root:root, 500 (rx)
B is me:root, 500 (rx)
C is me:root, 700 (rwx)
D.txt is me:root, 600 (rw)

If I `cp D.txt` to an identically owned and permissioned file structure on my Desktop that starts at B, everything is fine. On the other hand, if I use unison to copy the directory structure, it fails on an ownership change for a ".unison.D.txt.nnnnn" file. Is there a fix?

UNISON 2.48.3 started propagating changes at 02:53:54.51 on 20 Nov 2018

[BGN] Copying B/C/D.txt from /.../A to /home/me/Desktop/ [ie to /home/me/Desktop/B/C/D.txt]

Failed: Error in setting file ownership:
Operation not permitted [chown(/home/me/Desktop/B/C/.unison.testing.txt.a14bcb4fe76cb8c262af6a50e2043619.unison.tmp)]

Failed [B/C/D.txt]: Error in setting file ownership:
Operation not permitted [chown(/home/me/Desktop/B/C/.unison.testing.txt.a14bcb4fe76cb8c262af6a50e2043619.unison.tmp)]

UNISON 2.48.3 finished propagating changes at 02:53:54.51 on 20 Nov 2018

Background: I am trying to use unison & incron to backup Keybase's online file-system, which exists at /run/user/1000/keybase/kbfs. Below that directory, I find a collection of folders are all owned by me:root. All directories are mode 500 (rx), save one (/.../kbfs/private/me) which is 700 (rwx). All files are mode 600 (rw). I want that mirrored on my desktop.

[[e-mail] [unison-users]]

Post by Dave ***@niwas.net [unison-users]
Operation not permitted [chown(/home/me/Desktop/B/C/.unison.testing.txt.a14bcb4fe76cb8c262af6a50e2043619.unison.tmp)]

It's rather odd that Unison is attempting to change the ownership of
this file and failing. It seems like any file Unison creates will, by
default, get the UID:GID that Unison is running under, which should be
the UID:GID of your login. And given the details of the file structure
you've mentioned, clearly that is "me:root". IIRC, trying to change the
ownership of a file you own to your own UID:GID does nothing and is
always allowed.

When Unison aborts, does it leave the file there? And if so, what
user:group owns it? Also, what user:group is Unison running under? Is
it me:root?

Dale

['Benjamin C. Pierce' [e-mail] [unison-users]]

Running with

-debug all

will tell you a lot about the sequence of events before the failure. (It will also produce a mountain of output unless you use -path to focus Unison on just a few files that are giving problems.)

- B

Post by Dave ***@niwas.net [unison-users]
I have an issue with linux file/directory ownership that is allowing me to copy a file using `cp`, but not back it up via `unison`. The problem appears to be in the change of ownership for a temp file of `unison`'s. I'd like to know how to correct this.
/.../A/B/C/D.txt
A is root:root, 500 (rx)
B is me:root, 500 (rx)
C is me:root, 700 (rwx)
D.txt is me:root, 600 (rw)
If I `cp D.txt` to an identically owned and permissioned file structure on my Desktop that starts at B, everything is fine. On the other hand, if I use unison to copy the directory structure, it fails on an ownership change for a ".unison.D.txt.nnnnn" file. Is there a fix?
UNISON 2.48.3 started propagating changes at 02:53:54.51 on 20 Nov 2018
[BGN] Copying B/C/D.txt from /.../A to /home/me/Desktop/ [ie to /home/me/Desktop/B/C/D.txt]
Operation not permitted [chown(/home/me/Desktop/B/C/.unison.testing.txt.a14bcb4fe76cb8c262af6a50e2043619.unison.tmp)]
Operation not permitted [chown(/home/me/Desktop/B/C/.unison.testing.txt.a14bcb4fe76cb8c262af6a50e2043619.unison.tmp)]
UNISON 2.48.3 finished propagating changes at 02:53:54.51 on 20 Nov 2018
Background: I am trying to use unison & incron to backup Keybase's online file-system, which exists at /run/user/1000/keybase/kbfs. Below that directory, I find a collection of folders are all owned by me:root. All directories are mode 500 (rx), save one (/.../kbfs/private/me) which is 700 (rwx).. All files are mode 600 (rw). I want that mirrored on my desktop.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Dave [e-mail] [unison-users]]

This post might be inappropriate. Click to display it.

[Dave [e-mail] [unison-users]]

Post by Dave ***@niwas.net [unison-users]
Nov 22 9:03 AM

Post by ***@alum.mit.edu [unison-users]
Also, what user:group is Unison running under? Is it me:root?

I'm not sure how to tell that, but I presume it is me:me. Is there a way to change the group under which a program is running? And is there a way to do it when it's running as a daemon/ under incrond?

I'll add that it seems a bug that I would have to do this anyway. If I can copy files, I should be able to sync them with a folder that I can copy ftom/to. Why would unison not be content, only because it fails to change ownership of a file that isn't actually one that I'm asking it to sync, but something it needs for it's record keeping? It's record keeping needs, in other words, should not be breaking it's backup functionality.

Post by Dave ***@niwas.net [unison-users]

Post by ***@alum.mit.edu [unison-users]
Dale

Dave.

Dave

[[e-mail] [unison-users]]

Post by Dave ***@niwas.net [unison-users]
Well, part of my question is I don't understand linux
permissions/ownership very well. I would presume my user:group is
me:me, though I am also a member of various other groups, like
debian-tor for example.

The general rule in Unix (and I think Unison follows it) is that you can
successfully run things in two ways: One way is as a non-root user,
where the user can read/write everything it needs to read/write, and the
program does not pay attention to file ownership. The second way is as
root, in which case the program can do all sorts of manipulation.

In regard to Unison, if you want to run it as a non-root user, then you
have to avoid the -user and -group options, so Unison won't try to
change the ownership of things it creates. Then, everything it creates
will be owned by the user it is running under, rather than the owner of
the file/directory it copies.

One useful thing is to run the program "id". It tells the user and
group your shell is running under, as well as the "additional groups" of
the process. That's not complicated, but it's useful to remind yourself
of how you are running things.

Dale