Bug? Previously deleted groups coming back to life.

[jaypub]

New to FreeNAS.

Here's what I did....

Created 5 new groups. Let's call them groups "one" through "five" which were assigned GID 1000-1004.

[did other stuff - SMB shared a dataset as "openshare"]

Deleted share
Deleted dataset
Deleted those groups.

Created new group "newone" which is assigned GID 1000.
Created new dataset and assigned group "newone" as the owner.
Shared the dataset as "openshare" (again)

Connect to share in windows.... look at security settings in windows and share is owned by "one" rather than "newone"

Tried rebooting FreeNAS and the Windows client.

It still resolves owner group as the non-existent "one"

 

[jaypub]

Not sure if it is a a bug or what, but it persisted across client and freenas server reboots.

I'm probably doing it wrong, but the unexpected behavior there is scary just the same.

I have no idea where it might be "caching" the old (deleted) names associated with the groups/GID's - but it actually seems like it goes back to fetch them from FreeNAS (it takes 10 seconds or so from the windows side in security tab to resolve it).

This was a pretty big deal so we opted for another solution for now. Thanks.

 

[microserf]

Not sure if it is a a bug or what, but it persisted across client and freenas server reboots.

Did you cat /etc/group to see if they were still there?

I have no idea where it might be "caching" the old (deleted) names associated with the groups/GID's - but it actually seems like it goes back to fetch them from FreeNAS (it takes 10 seconds or so from the windows side in security tab to resolve it).

What were you doing/viewing when the 10 second delay was encountered?

Tried rebooting FreeNAS and the Windows client.

It still resolves owner group as the non-existent "one"

I was ready to blame Samba. Still might . What were you using as a boot deice?

 

[jaypub]

The whole freenas install is blown away now, so I'll try to help from memory:

Did you cat /etc/group to see if they were still there?

Not from shell. I confirmed the groups that were being resolved/listed on the windows side were missing from the Freenas > Groups list in the gui - which I assume cat's /etc/group and makes it tabled and pretty... so... yes? They were definitely deleted and the GID's became free for use and were recreated with different group names/purposes. That's the scary part.... even if it's just a wrong label that an admin managing permissions is seeing and whatever the actual/new group and its members are what will be applied.

What were you doing/viewing when the 10 second delay was encountered?

In the windows client, right click on the shared folder, properties, "Security" tab. The owner user is first shown as an unresolved... SID... it spins the hourglass or whatever for about 5-10 seconds and then resolves the old (confirmed deleted) FreeNAS group name rather than the new one. Again, persisted through reboot of both freenas / windows client. Also "net use * /delete" before the win client reboot for whatever that's worth.

What were you using as a boot deice?

Booting from 128gig SSD dedicated to FreeNAS boot.

 

[jaypub]

I guess it would be easy enough to replicate though:


- Create a group call it BADGUYS (note the GID...i.e. 1021)
- share something like "bankvault" out owned by that group.
- Try to access it on windows side.
- Delete the share
- Delete the group BADGUYS
- Create group GOODGUYS (should also be GID 1021)
- share the same sharename "bankvault" out with ownership to GOODGUYS

See what security tab says on the windows side

 

[microserf]

Created new dataset and assigned group "newone" as the owner.

Same name for the dataset?

I guess it would be easy enough to replicate though:

I'm going to try, just not immediately. Sometime this weekend. I'm about half way through a 6 million file copy that I do not want to restart.

 

[jaypub]

Same name for the dataset?

I think so. i.e. dataset=bankvault share=bankvault

but I might have made it more like dataset=ds-bankvault share=bankvault