Can I force ownership when new files are written to a dataset?

[NASbox]

I am running a syncthing client in a jail, and the sync directory dataset is set up as owner/group syncthing/syncthing.

I am copying files into/out of this directory with Winscp (Windows XP - I don't want to use NTLM v1 due to security issues.) using user ids that are part of the syncthing group. I would prefer use my regular login to put files in or take files out of the sync directory.

Files copied into the sync directory retain the login ID of the owner
If I forget to change the group ownership from the default, I can end up with a file:
-rwxr--r-- user syncthing
That won't be deleted properly. Is there a way to force -rwxrw-r-- and owner syncthing

Any suggestions woud be much appreciated.

 

[Samuel Tai]

Try the following in the share Auxiliary parameters:

force user = syncthing
force create mode = 0764

 

[NASbox]

Try the following in the share Auxiliary parameters:

force user = syncthing
force create mode = 0764

@Samuel Tai thanks for the reply - can you pleas clarify where I apply these parameters? Just to clarify, I am NOT using samba, but scp.

 

[Samuel Tai]

Just to clarify, I am NOT using samba, but scp.

Sorry, I didn't catch that the first time. WinSCP has the ability to create custom commands. You could try creating a custom command named Fix_ownership_and_permissions with content chmod 764 "!"; chown syncthing:syncthing "!". Then after a transfer, you can select the just transferred file, and apply the custom command.

 

[NASbox]

Sorry, I didn't catch that the first time. WinSCP has the ability to create custom commands. You could try creating a custom command named Fix_ownership_and_permissions with content chmod 764 "!"; chown syncthing:syncthing "!". Then after a transfer, you can select the just transferred file, and apply the custom command.

Thanks @Samuel Tai ... I guess that's possible, I was hoping that there was some sort of zfs inherit parameter that could force ownership within a database. If no such thing exists, I guess I will have to make syncthing a full user that has the ability to log in, but I would prefer not to do that

UPDATE: I just tried to manually change the ownership from user->syncthing with WindSCP and I got a permission error. Changing the group permissions worked fine.

 

[Samuel Tai]

OK, then you could run a cron job daily to fix the ownership in the syncthing folder. Something like find /mnt/path/to/syncthing -exec chown syncthing:syncthing {} \;.

 

[NASbox]

OK, then you could run a cron job daily to fix the ownership in the syncthing folder. Something like find /mnt/path/to/syncthing -exec chown syncthing:syncthing {} \;.

Thanks agin @Samuel Tai -- I just did some more experimenting and for some reason that I don't understand things seem to work regardless of the permissions.

First I sync a file from a remote nix box which ends up in the Syncthing sync jail directory (as seen from WinSCP on Windows XP
-rw-r--r-- 1 syncthing syncthing 47156 Apr 29 2019 TESTFILE.pdf
I can for reasons that I do not understand delete this file using WinSCP with the following user:
$ id uid=1001(user) gid=1001(user) groups=1001(user),0(wheel),983(syncthing)

likewise I can copy a file into the Syncthing sync jail from WinSCP like so:
-rw-r--r-- 1 user syncthing 47156 Apr 29 2019 TESTFILE.pdf
and Syncthing can still delete the file.

The sync jail owned by syncthing looks like this:
drwxrwx--- 7 syncthing syncthing 7 Jan 23 21:50 SYNCTHING
and the folder being synced looks like this:
drwxrwx--- 3 syncthing syncthing 13 Jun 15 15:23 MIGRATE_Syncthing

Just for completeness, to provide complete information:
I rooted into the freenas box to list the group membership of the syncthing user:

Code:

#>su syncthing
$>id
uid=983(syncthing) gid=983(syncthing) groups=983(syncthing)

and here is the running syncthing processes (and the grep of the ps):

Code:

#>ps aux | grep sync
root          24   0.0  0.0      0     16  -  DL   29May20      7:25.22 [syncer]
syncthing   5605   0.0  0.0   6388   1140  -  IsJ  29May20      0:00.00 daemon: /usr/local/bin/syncthing[5606] (daemon)
syncthing   5606   0.0  0.0 122492   9792  -  IJ   29May20      0:14.69 /usr/local/bin/syncthing -home=/usr/local/etc/syncthing -logfi
syncthing   5630   0.0  0.2 123964  69236  -  SNJ  29May20      9:25.79 /usr/local/bin/syncthing -home=/usr/local/etc/syncthing -logfi
root       26835   0.0  0.0   6704   2672  0  S+   15:38        0:00.00 grep sync

Is this because user is a member of wheel? I'm not sure why I can do what I am doing.... but at least it works.
I thought I understood nix permissions, but it seems that I have some gaps in my understanding... maybe just BSD... I'm a day-to-day linux user.
Any explanation/hints would be much appreciated...

 

[Samuel Tai]

No, it's because the user is a member of the syncthing group, and you've defined the permissions on the folder to allow full access (read/write/execute) for group members.

 

[NASbox]

Thanks again @Samuel Tai

No, it's because the user is a member of the syncthing group, and you've defined the permissions on the folder to allow full access (read/write/execute) for group members.

I'm confused... when does the directroy permission override the file permissions?

Code:

Directory RWXRWX---   syncthing/syncthing
file      RW-R-----   user/syncthing

I also tried this (logged in to root shell on FreeNAS and executed the following:

Code:

#>su syncthing
$>id
uid=983(syncthing) gid=983(syncthing) groups=983(syncthing)
$>rm xx.txt
override rw-r--r-- user/syncthing uarch for xx.txt? 

What is a uarch?
Replying yes allowed me to delete the file. Is this uarch connected with why syncthing can delete the file?

Thanks for all the help... I feel like a real NOOB.... (I thied google, but I was getting all sorts of pages about micro-architecture in various context -- I'm happy to read a decent reference on the finer points of this if anyone knows of something relevant.)

 

[Samuel Tai]

The file permissions only take effect if you were changing the files (appending, editing, truncating). The directory permissions take effect for any changes in the directory (creates/deletes).

uarch is short for micro-architecture (u faintly resembles the lower-case Greek mu), and in this context means the file permissions.