Migration to FreeNAS / Moving the file

[anodos]

Well, you can use setfacl, but that's not very efficient because it doesn't recurse through a directory. This means you will have to use find syntax will be something like

Code:

find /mnt/<path-to-share>/ -type f -exec setfacl <access control entry> {} \;

and then

Code:

find /mnt/<path-to-share>/ -type d -exec setfacl <access control entry> {} \;

I'm a bit concerned that your groups aren't showing up. I'm not able to reproduce it on my servers. You may want to file a bug report at bugs.freenas.org.

 

[BlazeStar]

Okay I just did / Bug #6723

But in the meantime, how can I make this work?

Should I revert my datasets to a UNIX ACL permission type and then set the appropriate groups for each shares ?

I really need to get this to work because I'm having all kind of weird permission problems, and I just want to rebuild my permission from scratch for every dataset, recursively and cleanly.

For example, by selecting all the users for a specific share and giving them all level of access EXCEP full control, I thought there would be no problem.

But some users have access only to some folders,etc.

I miss the good old CHMOD -R, and CHOWN -R, which would fix everything in no time.

The GUI is no help in this case since when I select "Windows" in permission type, then I cannot play with the permission settings.

So at this point, unless there's a magic fix for my group thing, I'm just looking for a solution clear all permissions and rebuild them from scratch.

I'd really like to see what my options are...

What happens if I just revert all dataset to UNIX permission type, and then CHMOD + CHOWN then with the right users and groups ?

 

[BlazeStar]

The problem may also be somehow related to your Windows client being a VM and on a different subnet. It's hard to say. Updating to the latest version of FreeNAS will exclude one possibility.

Just for the record, my VM is not on a different subnet.

And just to exclude the fact that the problem could be related to using a VM, created a new account for myself on a Windows 7 machine and the same problem occurs.

Just wanted to clear out the VM and subnet variables as being part of the problem.

 

[anodos]

Are you still having this problem? If so, try manipulating ACEs when logged in as local admin on windows client.

 

[alexg]

You need to map your unixgroups to Windows groups

net groupmap add ntgroup="ShareUsers" unixgroup=shareusers type=local

However, something strange going on with new Samba. It keeps re-assigning new SID, so I had to reset SID several times to the original value. There is a bug logged on this topic and may have been fixed in 9.2.1.9. Also, Windows security edit window doesn't show FreeNAS RDNs unless I use admin account on Windows. I have not been able to figure this out yet.

 

[Ericloewe]

Since this thread was never updated, here's the resolution:

Blaze,

Well, I can explain the issue here and you can post to the forum ;-)

The issue was with the samba group mappings happening before the samba SID was being saved. Also, there was a point when the samba SID didn't used to get saved. I do not recall the exact version, but I want to say it was 9.2.1.8. So every time FreeNAS would get rebooted, a new SID was generated. We originally didn't even have group mappings, so this didn't matter. Once the group mappings were introduced, it mattered. So, when I looked at your group mappings, you had several different SID values. The "fix" was brute force, as follows:

service samba_server stop

rm -rf /var/db/samba4/*
rm -rf /var/etc/private*

service ix-pre-samba start
service samba_server start

At this point, is where the bug occurs. The newly created group mappings at this point had a consistent SID, however, it was not THE SID that was now correct ;-) So, to fix that:

net groupmap delete # this should blow away all mappings
service ix-pre-samba start # create config (and group mapping) with known SID

Ugly hack, however, I did just commit the fix that does the right thing. I hope this helps ;-)

From https://bugs.freenas.org/issues/6723

My preliminary results show that doing

Code:

service samba_server stop

rm -rf /var/db/samba4/*
rm -rf /var/etc/private*

service ix-pre-samba start
service samba_server start

is enough to fix the problem on recent FreeNAS 9.3 releases (201506042008 currently).

 

[alexg]

Thanks. This also works on 9.2.1.7. Instead of ix-pre-samba service, I had to use ix-samba service.