3

I have two linux computers:

  • personal (arch, full root access)
  • workplace (ubuntu, no root access).

I am using "Unison" to sync some selected directories from one computer to an ext4 USB stick, and then moving the USB stick to the other computer and copying from that USB stick this other computer.

The UID of the user on my personal machine is the same as the UID of the sysadmin on the work machine, and both users got a umask of 0022 (edit: the users also happen to have different usernames).

I did not use any special settings for unison initially, and there have been some issues with permissions between the two computers.

Yesterday I noticed that on my personal machine, I could not open a file created on the work machine. I decided to switch to the perms = 0 setting on my Unison profile, and now things seem rather messed up.

What would be the optimal way to handle this situation here? Should I start syncing anew with perms=0 from the start, or is there another Unison setting (or combination of settings) that would enable this setup to work smoothly? Would it also be beneficial if I change the filesystem of the usb stick to exFAT to avoid such issues?

Update:

Trying to create a reproducible example (without perms=0).

  • I have a directory named test, created on the personal machine with filesystem type ext4, and synced to the flash drive.
  • I sync it from the flash drive to a test dir, created on the work machine's home dir, also on an ext4 filesystem.
  • Create a simple .odt file on work machine, within the test dir.

So far, from the work machine, we got:

❯ la /media/u0183918/sandisk256/test # Flash drive total 8.0K drwxrwx--- 2 sysmn gdm 4.0K Nov 26 09:44 figures/ drwxrwx--- 2 sysmn gdm 4.0K Nov 25 14:15 supplementary_code/ u0183918@set-l-lm25udx9w ~ ❯ ls -ld /media/u0183918/sandisk256/test drwxr-xr-x 4 sysmn gdm 4096 Nov 26 09:37 /media/u0183918/sandisk256/test/ ❯ la ~/test total 20K drwxrwx--- 2 u0183918 domain users 4.0K Nov 26 09:44 figures/ drwxrwx--- 2 u0183918 domain users 4.0K Nov 26 09:43 supplementary_code/ -rw-r--r-- 1 u0183918 domain users 8.7K Nov 26 09:46 testfile.odt ❯ ls -ld ~/test drwxr-xr-x 4 u0183918 domain users 4096 Nov 26 09:46 /home/u0183918/test/
  • After creating testfile.odt, I try to sync again:
❯ unison ~/test /media/u0183918/sandisk256/test/ Unison 2.53.7 (ocaml 5.2.0): Contacting server... Looking for changes Reconciling changes u0183918/... sandisk25... new file ----> testfile.odt [f] 1 items will be synced, 0 skipped 8.7 KiB to be synced from u0183918/test to sandisk256/test 0 B to be synced from sandisk256/test to u0183918/test Proceed with propagating updates? [] No default command [type '?' or F1 for help] Proceed with propagating updates? [] y Propagating updates Unison 2.53.7 (ocaml 5.2.0) started propagating changes at 09:56:05.91 on 26 Nov 2025 [BGN] Copying testfile.odt from /home/u0183918/test to /media/u0183918/sandisk256/test Failed [testfile.odt]: Error in copying locally: Permission denied [open(/media/u0183918/sandisk256/test/.unison.testfile.odt.ed66d4eef79419d08dc915c1bfb9a751.unison.tmp)] Unison 2.53.7 (ocaml 5.2.0) finished propagating changes at 09:56:05.91 on 26 Nov 2025, 0.000 s Saving synchronizer state Synchronization incomplete at 09:56:05 (0 items transferred, 0 skipped, 1 failed) failed: testfile.odt

Replacing unison with rsync -auv leads to similar permission issues.

Improve this question
0

3 Answers 3

Reset to default
5

Would it also be beneficial if I change the filesystem of the usb stick to exFAT to avoid such issues?

"Let's break the system some more in hopes it fixes a problem I don't really understand": sorry, but that's how that sounds! Let's avoid that. (also, no, that wouldn't change anything for the better.)

Instead, you should try to understand the issue you're trying to fix. It doesn't seem to be what you're addressing here.

Should I start syncing anew with perms=0

No. You shouldn't set perms=0 at all (that's not helpful under any circumstance); you should remove that setting.

Unison maps file owners and groups by the name of these users and groups. So, if you're for example arismav on your work machine and on your personal machine, then everything is fine; whatever problem you had needs to be solved differently than by setting perms=0. Full stop.

You should remove the setting, and probably do another sync in the same direction to restore intended permissions.

An alternative to mapping by user name: You can instead map by uid by using numericids, but that doesn't sound like it's what you want:

The UID of the user on my personal machine is the same as the UID of the sysadmin on the work machine

So, you because that means that your user on the work machine has a different uid than your user on your private machine, that won't work.

Generally, more complicated synchronization solutions solve that by implementing some kind of tables that allow you to translate between different uids or user names on different machines. Unison doesn't support that. You can work around that, but it is a separate topic that one could discuss when you can conclusively determine you need that.

Improve this answer
6
  • Thank you very much for the suggestion. The usernames, as well as the user UIDs between computers are different in this case. Also, may I ask why would perms=0 be a bad idea? Wouldn't that just lead to the user who mounts the usb being the owner of the files in each machine? Commented Nov 25 at 15:28
  • 3
    perms=0 masks all the permission bits, meaning that the destination has no permission bits set. You really do not want this, @arismav Commented Nov 25 at 15:57
  • Thank you for the input @ChrisDavies, but would it be possible to elaborate here? I'm certainly not the most experienced user out there, and I would benefit from some extra knowledge. Commented Nov 25 at 16:01
  • 3
    The permission bits are important parts of the information you're trying to synchronize. As you will have noticed, multiple programs stop working if the permissions are not as set. You haven't really specified what has become "rather messed up", so we can't be more specific, either, I'm afraid. Commented Nov 25 at 16:11
  • I see, thank you, I will provide more information soon. Commented Nov 25 at 19:59
1

Your unison command isn't attempting to reach the remote server as both side1 and side2 are given as local paths. This will synchronise the two local directory trees ~/test and /media/u0183918/sandisk256/test:

unison ~/test /media/u0183918/sandisk256/test

Since the directory /media/u0183918/sandisk256/test doesn't exist on this server the command will fail with permission failures (you're not root so you can't create directory trees underneath /media).

You probably want something like this:

unison -batch -prefer newer ~/test ssh://personalServer/media/u0183918/sandisk256/test
Improve this answer
9
  • Thanks Chris, but I am a bit confused now. How would I set up such a server? Commented Nov 26 at 15:37
  • You've got two machines, a and b. You need to tell unison to talk between them. Typically it's over ssh (like rsync) Commented Nov 26 at 15:54
  • So you suggest to remove the usb stick, and sync directly between the laptops via ssh? Or treat the usb as another computer somehow? I think the command you mention above implies the latter? Commented Nov 26 at 15:56
  • Oh. Are you synchronising from local to the USB stick, moving the USB stick to the other machine, and then synchronising from the USB stick to your target directory? If so, that wasn't at all obvious (to me) from your question. Commented Nov 26 at 17:41
  • 1
    You need to have the same numeric ID on both systems, or use a filesystem on the USB stick that cannot track userids such as exFAT Commented Nov 26 at 21:08
0

Reiterating one of the points of the original post:

Would it also be beneficial if I change the filesystem of the usb stick to exFAT to avoid such issues?

Just tested the minimal example above using another usb which has a vfat filesystem and it seems to work seamlessly (at least, for the simple scenarios I tested), since FAT does not store unix permissions.

edit: I switched my USB drive to exFAT and I've been testing it with several different conflict scenarios. It seems quite robust, could not manage to break it (yet).

Would there be any disadvantage to such a setup?

P.S. the usb is LUKS-encrypted so I assume safety would not be an issue here.

Improve this answer
1
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. Commented Nov 27 at 1:34

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.