Linux file/directory ownership: I can cp a file but not backup via unison
up vote
1
down vote
favorite
I have a question on Linux file/directory ownership that is allowing me to copy a file using cp, but not back it up via the utility 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 my own (/.../kbfs/private/me) which is 700 (rwx). All files are mode 600 (rw). I want that mirrored on my desktop.
file-permissions ubuntu-18.04 unison keybase incron
edited Nov 25 at 1:50
fixer1234
17.4k144281
asked Nov 21 at 1:07
Diagon
431414
add a comment |
up vote
1
down vote
favorite
I have a question on Linux file/directory ownership that is allowing me to copy a file using cp, but not back it up via the utility 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 my own (/.../kbfs/private/me) which is 700 (rwx). All files are mode 600 (rw). I want that mirrored on my desktop.
file-permissions ubuntu-18.04 unison keybase incron
edited Nov 25 at 1:50
fixer1234
17.4k144281
asked Nov 21 at 1:07
Diagon
431414
1
It looks to me that the error is not copying the file, but rather retaining the ownership permissions. Is /home a local disk (if so, what partition type) or some kind of mount - and if the latter, is it using SMB, NFS or something else?
– davidgo
Nov 21 at 1:26
/home is a btrfs subvolume, @home which, with @ (root) are on the same primary partition of my SSD.
– Diagon
Nov 21 at 1:28
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have a question on Linux file/directory ownership that is allowing me to copy a file using cp, but not back it up via the utility 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 my own (/.../kbfs/private/me) which is 700 (rwx). All files are mode 600 (rw). I want that mirrored on my desktop.
file-permissions ubuntu-18.04 unison keybase incron
edited Nov 25 at 1:50
fixer1234
17.4k144281
asked Nov 21 at 1:07
Diagon
431414
I have a question on Linux file/directory ownership that is allowing me to copy a file using cp, but not back it up via the utility 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 my own (/.../kbfs/private/me) which is 700 (rwx). All files are mode 600 (rw). I want that mirrored on my desktop.
file-permissions ubuntu-18.04 unison keybase incron
file-permissions ubuntu-18.04 unison keybase incron
edited Nov 25 at 1:50
fixer1234
17.4k144281
asked Nov 21 at 1:07
Diagon
431414
edited Nov 25 at 1:50
fixer1234
17.4k144281
asked Nov 21 at 1:07
Diagon
431414
edited Nov 25 at 1:50
fixer1234
17.4k144281
edited Nov 25 at 1:50
fixer1234
17.4k144281
edited Nov 25 at 1:50
fixer1234
17.4k144281
17.4k144281
asked Nov 21 at 1:07
Diagon
431414
asked Nov 21 at 1:07
Diagon
431414
asked Nov 21 at 1:07
Diagon
431414
431414
1
It looks to me that the error is not copying the file, but rather retaining the ownership permissions. Is /home a local disk (if so, what partition type) or some kind of mount - and if the latter, is it using SMB, NFS or something else?
– davidgo
Nov 21 at 1:26
/home is a btrfs subvolume, @home which, with @ (root) are on the same primary partition of my SSD.
– Diagon
Nov 21 at 1:28
add a comment |
1
It looks to me that the error is not copying the file, but rather retaining the ownership permissions. Is /home a local disk (if so, what partition type) or some kind of mount - and if the latter, is it using SMB, NFS or something else?
– davidgo
Nov 21 at 1:26
/home is a btrfs subvolume, @home which, with @ (root) are on the same primary partition of my SSD.
– Diagon
Nov 21 at 1:28
1
1
It looks to me that the error is not copying the file, but rather retaining the ownership permissions. Is /home a local disk (if so, what partition type) or some kind of mount - and if the latter, is it using SMB, NFS or something else?
– davidgo
Nov 21 at 1:26
It looks to me that the error is not copying the file, but rather retaining the ownership permissions. Is /home a local disk (if so, what partition type) or some kind of mount - and if the latter, is it using SMB, NFS or something else?
– davidgo
Nov 21 at 1:26
/home is a btrfs subvolume, @home which, with @ (root) are on the same primary partition of my SSD.
– Diagon
Nov 21 at 1:28
/home is a btrfs subvolume, @home which, with @ (root) are on the same primary partition of my SSD.
– Diagon
Nov 21 at 1:28
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
The problem does not appear to be unison, but the fact that on one side of the copy is a filesystem run by keybase. Keybase is allowing me to write into it's directory and reporting me:root ownership, but when unison tries to create a me:root file on my Desktop, it fails. I understand that filesystems can pretty much report anything they want regarding permissions and behave any way they want regarding ability to read/write/execute.
The solution for unison is to use group = false to keep it from trying to sync the root ownership. In that case, it also needs perms = 0o1700 to avoid trying to set the root's or others' permission bits.
That works when unison is run from the cli, but is continuing to present problems when used with incrond - but that's for another question...
answered Nov 24 at 9:34
Diagon
431414
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
The problem does not appear to be unison, but the fact that on one side of the copy is a filesystem run by keybase. Keybase is allowing me to write into it's directory and reporting me:root ownership, but when unison tries to create a me:root file on my Desktop, it fails. I understand that filesystems can pretty much report anything they want regarding permissions and behave any way they want regarding ability to read/write/execute.
The solution for unison is to use group = false to keep it from trying to sync the root ownership. In that case, it also needs perms = 0o1700 to avoid trying to set the root's or others' permission bits.
That works when unison is run from the cli, but is continuing to present problems when used with incrond - but that's for another question...
answered Nov 24 at 9:34
Diagon
431414
add a comment |
up vote
0
down vote
accepted
The problem does not appear to be unison, but the fact that on one side of the copy is a filesystem run by keybase. Keybase is allowing me to write into it's directory and reporting me:root ownership, but when unison tries to create a me:root file on my Desktop, it fails. I understand that filesystems can pretty much report anything they want regarding permissions and behave any way they want regarding ability to read/write/execute.
The solution for unison is to use group = false to keep it from trying to sync the root ownership. In that case, it also needs perms = 0o1700 to avoid trying to set the root's or others' permission bits.
That works when unison is run from the cli, but is continuing to present problems when used with incrond - but that's for another question...
answered Nov 24 at 9:34
Diagon
431414
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
The problem does not appear to be unison, but the fact that on one side of the copy is a filesystem run by keybase. Keybase is allowing me to write into it's directory and reporting me:root ownership, but when unison tries to create a me:root file on my Desktop, it fails. I understand that filesystems can pretty much report anything they want regarding permissions and behave any way they want regarding ability to read/write/execute.
The solution for unison is to use group = false to keep it from trying to sync the root ownership. In that case, it also needs perms = 0o1700 to avoid trying to set the root's or others' permission bits.
That works when unison is run from the cli, but is continuing to present problems when used with incrond - but that's for another question...
answered Nov 24 at 9:34
Diagon
431414
The problem does not appear to be unison, but the fact that on one side of the copy is a filesystem run by keybase. Keybase is allowing me to write into it's directory and reporting me:root ownership, but when unison tries to create a me:root file on my Desktop, it fails. I understand that filesystems can pretty much report anything they want regarding permissions and behave any way they want regarding ability to read/write/execute.
The solution for unison is to use group = false to keep it from trying to sync the root ownership. In that case, it also needs perms = 0o1700 to avoid trying to set the root's or others' permission bits.
That works when unison is run from the cli, but is continuing to present problems when used with incrond - but that's for another question...
answered Nov 24 at 9:34
Diagon
431414
edited Nov 24 at 12:08
answered Nov 24 at 9:34
Diagon
431414
answered Nov 24 at 9:34
Diagon
431414
answered Nov 24 at 9:34
Diagon
431414
431414
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1377145%2flinux-file-directory-ownership-i-can-cp-a-file-but-not-backup-via-unison%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
It looks to me that the error is not copying the file, but rather retaining the ownership permissions. Is /home a local disk (if so, what partition type) or some kind of mount - and if the latter, is it using SMB, NFS or something else?
– davidgo
Nov 21 at 1:26
/home is a btrfs subvolume, @home which, with @ (root) are on the same primary partition of my SSD.
– Diagon
Nov 21 at 1:28