In our old OBSD fileserver we could use chown, chgrp, chmod to manage the users/groups in the samba shares. In that machine I had each user as a "system" user and each added via smbpasswd as well. Groups were just in /etc/group and all was merry, Now we've switched to AD, and wbinfo, getent passwd and getent group are working nicely.
So, rsyncing from the old to the new is fine, and since I could not reuse the exact uid's and gid's I wrote a script like:
find /mnt/tonantzin/pandora -uid 1008 -exec chown 1136 {} +
find /mnt/tonantzin/pandora -gid 1010 -exec chgrp 1177 {} +
(one per line for about 50 users and 20 groups, probably not the most efficient way to do it because of the multiple find across the whole filesystem but for once, to migrate, it's no biggie).
The permissions were changed as expected but connecting via Samba from Windows did not work as expected.
After reading posts for a few days, though reluctant, I decided to follow people's advice and depend only on Windows ACL's, because now newer versions of samba (as of version 4, i believe, and apparently i was handling permissions wrong, before) are more "strict," and a humming in the back of my head says, "sure, I may not be comfortable having to depend on MS's unclear changes between versions, and occult behind the scenes poofery, but now I'll be able to assign more than one user, and or group to different slices of data with different permissions each."
So, on to giving one admin user total windows permissions through the FreeNAS GUI, and then connecting as that user from Windows and setting ACL's through Windows (right-click on the folder=>properties=> permissions).
After that, I can make sure the permissions have a "+" sign at the end, meaning ACL, as in:
-rwxrwxrwx+ 1 ETCETERA\jquiros ETCETERA\etcscontaprod 905754 Jan 5 17:39 MSTINV.DBF*
versus before:
-rwxrwxrwx 1 ETCETERA\jquiros ETCETERA\etcscontaprod 905754 Jan 5 17:39 MSTINV.DBF*
Mounting both old and new on a windows box is also not an option (network speeds, single-threaded samba, etc, would make downtime horrendous).
To minimize downtime during the migration, I would like to script the permissions changes on the freenas box itself, instead of having to sort through the different folder from a windows box and manually go through.
I read that setfacl does not have a recursive switch. I have also not found easily digestable docs on setfacl.
Any ideas on using getfacl across the filesystem, to then be able to use the output of how it is left (fed with fetfacl?) in a script with setfacl?
My idea would be:
1) rsync data to the new server- live production keeps using the old server.
2) set all the ACL's on the new server from a Windows Box.
3) create a script using the ACL info on the non-live, new server.
4) shut everyone out of the production server (kill smbd, snmbd, etc).
5) rsync changed (-u) files to new server
6) run the ACL-applying script (from step 3)
7) Map people's drives to the new server.
8) Carry on and get on with other urgencies.
Any pointers appreciated, in helping me make this rather-subjective-to-me "bug" become a feature.
Jon Q
So, rsyncing from the old to the new is fine, and since I could not reuse the exact uid's and gid's I wrote a script like:
find /mnt/tonantzin/pandora -uid 1008 -exec chown 1136 {} +
find /mnt/tonantzin/pandora -gid 1010 -exec chgrp 1177 {} +
(one per line for about 50 users and 20 groups, probably not the most efficient way to do it because of the multiple find across the whole filesystem but for once, to migrate, it's no biggie).
The permissions were changed as expected but connecting via Samba from Windows did not work as expected.
After reading posts for a few days, though reluctant, I decided to follow people's advice and depend only on Windows ACL's, because now newer versions of samba (as of version 4, i believe, and apparently i was handling permissions wrong, before) are more "strict," and a humming in the back of my head says, "sure, I may not be comfortable having to depend on MS's unclear changes between versions, and occult behind the scenes poofery, but now I'll be able to assign more than one user, and or group to different slices of data with different permissions each."
So, on to giving one admin user total windows permissions through the FreeNAS GUI, and then connecting as that user from Windows and setting ACL's through Windows (right-click on the folder=>properties=> permissions).
After that, I can make sure the permissions have a "+" sign at the end, meaning ACL, as in:
-rwxrwxrwx+ 1 ETCETERA\jquiros ETCETERA\etcscontaprod 905754 Jan 5 17:39 MSTINV.DBF*
versus before:
-rwxrwxrwx 1 ETCETERA\jquiros ETCETERA\etcscontaprod 905754 Jan 5 17:39 MSTINV.DBF*
Mounting both old and new on a windows box is also not an option (network speeds, single-threaded samba, etc, would make downtime horrendous).
To minimize downtime during the migration, I would like to script the permissions changes on the freenas box itself, instead of having to sort through the different folder from a windows box and manually go through.
I read that setfacl does not have a recursive switch. I have also not found easily digestable docs on setfacl.
Any ideas on using getfacl across the filesystem, to then be able to use the output of how it is left (fed with fetfacl?) in a script with setfacl?
My idea would be:
1) rsync data to the new server- live production keeps using the old server.
2) set all the ACL's on the new server from a Windows Box.
3) create a script using the ACL info on the non-live, new server.
4) shut everyone out of the production server (kill smbd, snmbd, etc).
5) rsync changed (-u) files to new server
6) run the ACL-applying script (from step 3)
7) Map people's drives to the new server.
8) Carry on and get on with other urgencies.
Any pointers appreciated, in helping me make this rather-subjective-to-me "bug" become a feature.
Jon Q
Last edited:
