Files/Folders created on samba (windows) via one user, has the permissions of another user?

[HungrySkeltal]

Hi everyone.

I've come to a rather strange issue that I haven't been able to work out - hoping someone here is a little smarter than I am!

I've created a dataset I've named 'jailData' and shared it via samba, which has the following permissions:

under which there is another dataset named 'grav', which has the following permissions:

I've also created a jail, named 'grav' which is hosting an instance of grav locally. It's all installed and working ok. I have mounted the ```/mnt``` directory of the jail to the 'jailData/grav' dataset.

now the strange thing is that when I use the jailData samba share, authenticated as 'boz' (as I have a million times before), and create a file or folder in the 'jailData/grav' dataset (specifically, ```/mnt/grav/user/pages/```), it will let me create the file, but then, I cannot edit it. I check the permissions, and they appear to instantly change to the user 'grav' within the jail:

This is very peculiar, as I created the folder as the user 'boz'. Further, if I try to edit/delete the folder via the samba share, it says I need permission from 'FREENAS/boz' to edit. Yet I am authenticated as boz, created it as boz, but the permissions are showing as grav?

Been fiddling with this for hours with no luck! Any help would be awesome.

Further info that may be useful:
-user created inside the jail named 'grav' with sudo
-if I sudo my way through everything inside the jail, with www as the owner, all my pages etc work nicely and grav can read it all with no issues. I just cannot do anything via windows. Is it something to do with the sudo user within the jail doing something funky maybe?

Thanks in advance!

 

[anodos]

Hi everyone.

I've come to a rather strange issue that I haven't been able to work out - hoping someone here is a little smarter than I am!

I've created a dataset I've named 'jailData' and shared it via samba, which has the following permissions:
View attachment 39363
under which there is another dataset named 'grav', which has the following permissions:
View attachment 39364

I've also created a jail, named 'grav' which is hosting an instance of grav locally. It's all installed and working ok. I have mounted the ```/mnt``` directory of the jail to the 'jailData/grav' dataset.

now the strange thing is that when I use the jailData samba share, authenticated as 'boz' (as I have a million times before), and create a file or folder in the 'jailData/grav' dataset (specifically, ```/mnt/grav/user/pages/```), it will let me create the file, but then, I cannot edit it. I check the permissions, and they appear to instantly change to the user 'grav' within the jail:
View attachment 39365
This is very peculiar, as I created the folder as the user 'boz'. Further, if I try to edit/delete the folder via the samba share, it says I need permission from 'FREENAS/boz' to edit. Yet I am authenticated as boz, created it as boz, but the permissions are showing as grav?

Been fiddling with this for hours with no luck! Any help would be awesome.

Further info that may be useful:
-user created inside the jail named 'grav' with sudo
-if I sudo my way through everything inside the jail, with www as the owner, all my pages etc work nicely and grav can read it all with no issues. I just cannot do anything via windows. Is it something to do with the sudo user within the jail doing something funky maybe?

Thanks in advance!

Compare output of "id boz" in your FreeNAS server and "id grav" in your jail. they probably have the same uid number.

 

[HungrySkeltal]

Compare output of "id boz" in your FreeNAS server and "id grav" in your jail. they probably have the same uid number.

Thanks for your reply, Anados - you're right!

I've changed the uid of 'grav' to 5000, however I'm still facing the same issue (even with newly created files/folders using the new uid of 5000). Any thoughts?

 

[HungrySkeltal]

I have figured it out. Turns out I had to recursively apply the set of ACLs (per my screenshots above). Everything is now tested and working as expected.
I am guessing there was some strange issues with permissions created during setup that just needed to be overwritten with the correct ones.
Thank you Anodos :)