Tony Ellis wrote:

see https://groups.yahoo.com/neo/groups/unison-users/conversations/messages?messageStartId=12228&archiveSearch=true

There is quite a discussion at the moment about permissions and unison - you might like to join and contribute...

Thanks again Tony.
I'm subscribed to the Unison mail group and have been watching the permission issue. It isn't what I've been seeing so I may need to start a new topic there.
I'm still not sure that this is a Unison issue and not a COS 7.3 Flexshare/SMB issue.
I'm managing for the moment doing a double sync or manually changing the permissions on the server. Slow and frustrating yes, but I want to figure out the why and fix it properly.

see https://groups.yahoo.com/neo/groups/unison-users/conversations/messages?messageStartId=12228&archiveSearch=true

There is quite a discussion at the moment about permissions and unison - you might like to join and contribute...

nuke wrote:

I will try to do a sync with a completely new set of files to test this out also and run Unison in debug mode. Perhaps that will shed some light on what is happening.

Here is the results so far.

All files started on MBP with 644.

Created a new directory in /home/user called Test. Directory was created 755.

I used an empty Unison prefs file (only containing the two roots) and the files that end up on the COS server are 744. I deleted and recreated the COS folder.

I used my typical Unison prefs and the files that ended up on the COS server are also 744. I deleted and recreated the COS folder.

I used perms = 0 and dontchmod = true and ended up with the files on the COS server are 700.

Made another test. Instead of connecting via smb, I tried cifs. The behaviour on the first sync is the same. The files in the original folder are 644. First sync makes them 744 on the COS server. Second sync identifies all files having the wrong permissions. This is correct. If I do a global write prefs to server, the server files finally get the 644 permissions. With the second sync for only permissions, those files remain OK.

If I now add a new file to the original folder, that file ends up with the wrong permissions on the first sync. Unison catches the permission issue on the second sync and fixes it.

The log files doesn't add any additional info.

My head is spinning right now. I have a work around by doing 2 syncs when I add files but that is a pain in the butt. I'm not sure what to do.

Thanks in advance for any guidance.

Tony Ellis wrote:

OK - just did an experiment with permissions... this is with an empty profile file
First named system is Fedora - Second named system is ClearoS 7.3 - command line as per previous append
The unison command is run on the ClearOS system...
So you have something other than unison at play there...

Thank you for your detailed reply and help on figuring this out.

I probably should have mentioned that the COS7.3 server is acting as the central repository for two devices. Both MBP and Android Tablet sync files with the Server. This is so I can have the files in the sync directory with me when I only take my tablet on the road. So the sync looks like: MBP <-> COS7.3 <-> Android Tablet

The very strange thing is the the Android prefs are exactly as they should be, ie. 644. So it would appear that FolderSync is changing permissions on the tablet to the right settings even if the COS7.3 files are not.

I will try to do a sync with a completely new set of files to test this out also and run Unison in debug mode. Perhaps that will shed some light on what is happening.

Thanks again.

OK - just did an experiment with permissions... this is with an empty profile file
First named system is Fedora - Second named system is ClearoS 7.3 - command line as per previous append
The unison command is run on the ClearOS system...
So you have something other than unison at play there...

Created some files on the Fedora system like this by copying and setting different permissions

[sraellis@sophia Ancestry]$ ls -lad JohnEllis1830*

-rwxrwx--- 1 sraellis sraellis 1570546 Oct  4 12:21 JohnEllis1830-A.png

-rw-r--r-- 1 sraellis sraellis 1570546 Oct  4 12:21 JohnEllis1830-B.png

-r--r--r-- 1 sraellis sraellis 1570546 Oct  4 12:21 JohnEllis1830-C.png

-rw-rw---- 1 sraellis sraellis 1570546 Oct  4 12:22 JohnEllis1830-D.png

-rwx------ 1 sraellis sraellis 1570546 Oct  4 12:22 JohnEllis1830-E.png

-rw-rw---x 1 sraellis sraellis 1570546 Oct  4 12:22 JohnEllis1830-F.png

-rw------- 1 sraellis sraellis 1570546 Oct  4 12:22 JohnEllis1830-G.png

-r--r----- 1 sraellis sraellis 1570546 Oct  4 12:22 JohnEllis1830-H.png

-rw-r--r-- 1 sraellis sraellis 1570546 Jan 20  2014 JohnEllis1830.png

Ran the unison command and this is what ended up on the 7.3 system

[sraellis@karien Ancestry]$ ls -lad JohnEllis1830*

-rwxrwx--- 1 sraellis allusers 1570546 Oct  4 12:25 JohnEllis1830-A.png

-rw-r--r-- 1 sraellis allusers 1570546 Oct  4 12:25 JohnEllis1830-B.png

-r--r--r-- 1 sraellis allusers 1570546 Oct  4 12:25 JohnEllis1830-C.png

-rw-rw---- 1 sraellis allusers 1570546 Oct  4 12:25 JohnEllis1830-D.png

-rwx------ 1 sraellis allusers 1570546 Oct  4 12:25 JohnEllis1830-E.png

-rw-rw---x 1 sraellis allusers 1570546 Oct  4 12:25 JohnEllis1830-F.png

-rw------- 1 sraellis allusers 1570546 Oct  4 12:25 JohnEllis1830-G.png

-r--r----- 1 sraellis allusers 1570546 Oct  4 12:25 JohnEllis1830-H.png

-rw-r--r-- 1 sraellis allusers 1570546 Oct  2 16:14 JohnEllis1830.png

Edit - changing permissions also gets noticed..
On the Fedora system changed this one to 644

-rw-r--r-- 1 sraellis sraellis 1570546 Oct  4 12:21 JohnEllis1830-A.png

on running unison

props    <-?-> props      /  

props    ---->            JohnEllis1830-A.png  

[BGN] Copying properties for JohnEllis1830-A.png from //sophia//home/sraellis/Dropbox/Ancestry to /home/sraellis/Ancestry

[END] Copying properties for JohnEllis1830-A.png

Synchronization complete at 12:57:42  (1 item transferred, 0 skipped, 0 failed)

and we now have on 7.3

-rw-r--r-- 1 sraellis allusers 1570546 Oct  4 12:25 JohnEllis1830-A.png

Tony Ellis wrote:

Hmm - the doc doesn't mention perms being 0 as a pre-req
the profile becomes :-

perms = 0 

dontchmod = true

Tried that on my machine and it ran OK...
(not that it's required here...)

Tony, thanks again for taking time to reply.

I made that change to my prf file and re-ran Unison. I got

Fatal Error



Internal error: New archives are not identical.

Retaining original archives.  Please run Unison again to bring them up to date.

Interestingly enough, the sync still happened.

Now the file changed have permissions:

-rwxr--r--@

and the new file has

-rwx------

This is wacky.
=====
More more update.

It appears to be all new files that go onto into the /home/user folder and only some doc/pdf/xls files that haven't been changed. For example there are a number of pdf files that are rw-r--r-- on my MBP/user/PA/Metho... They have the right permissions. Unison goes to update the file and I set it to update files TO the COS server.

For whatever reason the COS server has them as rwxr--r--. No matter what I do, they end up as rwxr--r-- !

From Unison:

Valuation/Valuation Presentations 2007/Session_1_Howard_Riback_Guidelines.pdf

PA/Metho... : unchanged file     modified on 2017-10-03 at 14:24:30  size 65939     rw-r--r-- PDF  prvw

MobileSyn... : changed file       modified on 2017-10-03 at 14:24:30  size 61925     rwxr--r--

Server shows

-rwxr--r--   1 user  staff    60K  3 Oct 14:24 Session_1_Howard_Riback_Guidelines.pdf

Aaaaaaahhhhh!

Hmm - the doc doesn't mention perms being 0 as a pre-req
the profile becomes :-

perms = 0 

dontchmod = true

Tried that on my machine and it ran OK...
(not that it's required here...)

nuke wrote:

Tony Ellis wrote:

What happens if you add "dontchmod = true" to your preferences file?
http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#prefs
...
If this doesn't work, then would look at what samba and flexshares are doing under the covers. Since flexshares are not used here, my samba share setup is decidedly "non-ClearOS" like - cannot therefore help you with that... hate any 'automagic' that happens that yields unexpected results...

Thanks Tony.

I'll try the dontchmod in the Unison preference file and report back what I find.

I tried the dontchmod preference and got a fatal error. Ouch.

Fatal Error
If the 'dontchmod' preference is set, the 'perms' preference should be 0

I ran the sync and see that the process of creating a file in the /home/user/ folder makes the file 0744. All other files in the directory are 0644. But I suspect that I changed the prefs for those in the subsequent Unison sync. I don't think the files should be created on the server with 0744.

I forgot that I had installed Netatalk on the 5.2 server so I was connecting with AFP instead of SMB. So maybe that is why I didn't have the pref issues problem before. ???

Nick Howitt wrote:

OK I was slightly out. Flexshare definitions are in /etc/samba/flexshare.conf and are governed by the two parameters:

	directory mask = 0775

	create mask = 0664

Google "man smb.conf" to find more info. Unfortunately you can't really change them as every time you change something in the webconfig flexshare menu, this file gets rewritten. You could set the immutable bit "chattr +i /etc/samba/flexshare.conf" to stop ClearOS from changing the file but you'd need to remember to change it back when you wanted to make a genuine change.

Thanks Nick.

This sounds a bit strange. So the flexshare will over write the samba preferences? I'm going to check out the Flexshare preference and see if I can find smb.conf.

Isn't there some complication with Samba4 and the windows domain controller and preferences? From Samba Wiki

Instead of using Windows access control lists (ACL), you can set up a share using POSIX ACLs on your Samba server. However, when using POSIX ACL to set permissions, you must create the home directory for each new user manually and set permissions.

We don't have any Windows machines here so I chose to install OpenLDAP.

Will report back.

Tony Ellis wrote:

What happens if you add "dontchmod = true" to your preferences file?
http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#prefs
...
If this doesn't work, then would look at what samba and flexshares are doing under the covers. Since flexshares are not used here, my samba share setup is decidedly "non-ClearOS" like - cannot therefore help you with that... hate any 'automagic' that happens that yields unexpected results...

Thanks Tony.

I'll try the dontchmod in the Unison preference file and report back what I find.

OK I was slightly out. Flexshare definitions are in /etc/samba/flexshare.conf and are governed by the two parameters:

	directory mask = 0775

	create mask = 0664

Google "man smb.conf" to find more info. Unfortunately you can't really change them as every time you change something in the webconfig flexshare menu, this file gets rewritten. You could set the immutable bit "chattr +i /etc/samba/flexshare.conf" to stop ClearOS from changing the file but you'd need to remember to change it back when you wanted to make a genuine change.

Within the flexshares I think permissions are controlled from /etc/samba/smb.conf. There is also a daily cron job which may overwrite permissions. I'll check when I'm home.

Use unison here on 7.3 and don't have this problem - but then don't use samba with unison... permissions are identical in both directories.
my batch file runs on ClearOS 7.3, using crontab and ssh... sophia is a Fedora workstation - ssh private/public keys, passphrase and keychain allow this to run with automatic login nightly...

/usr/bin/su sraellis -l -c "/usr/bin/unison -batch -terse ssh://sophia-1.sraellis.com//home/sraellis/Dropbox/Ancestry /home/sraellis/Ancestry" &

What happens if you add "dontchmod = true" to your preferences file?
http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#prefs

The preferences file is usually "/userid_home/.unison/default.prf
eg root "/root/.unison/default.prf"
eg sraellis user "/home/sraellis/.unison/default.prf"

If this doesn't work, then would look at what samba and flexshares are doing under the covers. Since flexshares are not used here, my samba share setup is decidedly "non-ClearOS" like - cannot therefore help you with that... hate any 'automagic' that happens that yields unexpected results...