Announcing FreeNAS 9.2.1-RELEASE

[jyavenard]

agreed. hence why i said it was a workaround noted in the bug ticket. not a fix for the unexpected behavior regarding how SAMBA is dealing with ACLs vs UNIX permissions

heck, even the ticket's assignee recently posted this:

installed 9.2.1.1; I did reset the ownership/permission of my dataset using the GUI.
In the CIFS share settings I removed the inherit bits I had added earlier.

And it's all seem okay now. I can modify files I've created, and modify existing files too (I'm in the group permission)

Installed a new port jail, pkg works again ! great...

 

[GaiusBaltar]

installed 9.2.1.1; I did reset the ownership/permission of my dataset using the GUI.
In the CIFS share settings I removed the inherit bits I had added earlier.

And it's all seem okay now. I can modify files I've created, and modify existing files too (I'm in the group permission)

Installed a new port jail, pkg works again ! great...

awesome! i just finished upgrading to 9.2.1.1 myself.
CIFS shares working as expected once again with reset ACLs.
now that the upgrade is done i can sleep soundly :)

 

[Ruda Porto Filgueiras]

I also suffer with this issue on 9.2.1 and after upgrade to 9.2.1.1 the permission problem was solved.

But I'm facing with another strange issue: smbd process hanging and using 100% CPU.

Windows 7 CIFS clients reporting share window hangup until I kill the affected smbd process from that user.

Anyone has observerd such beharvior?

 

[Cosmo_Kramer]

I also suffer with this issue on 9.2.1 and after upgrade to 9.2.1.1 the permission problem was solved.

But I'm facing with another strange issue: smbd process hanging and using 100% CPU.

Windows 7 CIFS clients reporting share window hangup until I kill the affected smbd process from that user.

Anyone has observerd such beharvior?

I think this is the same issue as I am having:
https://bugs.freenas.org/issues/4285
If this is the same problem, please post in there as well.

 

[Ruda Porto Filgueiras]

I did downgrade to FreeNAS 9.2.0.

I don't need samba 4.1 new features, and 3.6.22 is more stable release.
On my setup with OpenLDAP, samba 4.1 have trouble top map grup GID to samba groupmap SID.

Some time it works, some time not, and CPU 100% also make things worst. :-(

I have plan do migrate to samba 4.1 ADS in future.

Cheers,

 

[Savell Martin]

installed 9.2.1.1; I did reset the ownership/permission of my dataset using the GUI.
In the CIFS share settings I removed the inherit bits I had added earlier.

And it's all seem okay now. I can modify files I've created, and modify existing files too (I'm in the group permission)

Installed a new port jail, pkg works again ! great...

I still have this problem if I tick inherit permissions...

Thing is I would like it to inherit those permissions so what's the issue?!
I don't understand if the bug is closed why is this still an issue?

Or why is it that we have to use a work around?
Are they saying that this is the intended functionality?

 

[laneige]

I've been getting some friends hooked on FreeNAS and PMS. Thanks!

 

[jkh]

I still have this problem if I tick inherit permissions...

Thing is I would like it to inherit those permissions so what's the issue?!

Here's the deal - inherit permissions and inherit owner are effectively *meaningless* now for Samba4 in the presence of proper ACLs. The only reason they are there at all is to try and simulate the behavior in an improperly configured environment (e.g. after the ACL check, Samba steps in and tries to "pretend" the ACL was properly set). The right fix is NOT to use these flags, and in fact when a dataset is now configured as a "Windows" dataset (see the option in the dataset creation dialog) those options are ignored completely because it's a bug to override the ACL behavior.

Don't use those options. They're hacks. Use ACLs for Windows.

 

[GaiusBaltar]

Here's the deal - inherit permissions and inherit owner are effectively *meaningless* now for Samba4 in the presence of proper ACLs. The only reason they are there at all is to try and simulate the behavior in an improperly configured environment (e.g. after the ACL check, Samba steps in and tries to "pretend" the ACL was properly set). The right fix is NOT to use these flags, and in fact when a dataset is now configured as a "Windows" dataset (see the option in the dataset creation dialog) those options are ignored completely because it's a bug to override the ACL behavior.

Don't use those options. They're hacks. Use ACLs for Windows.

is there any way to change an already created dataset's "share type" from UNIX to WINDOWS after it's been created (was created when running 9.2.0. while now i'm at 9.2.1.1). just curious since its greyed out when looking at the dataset's permissions in the GUI.

 

[cyberjock]

I'm closing this thread as 9.2.1 is no longer the latest version. 9.2.1.1 was released since there were serious bugs with 9.2.1.

GaiusBaltar: I'm not sure if you can convert from one to the other, but you could easily make a new dataset and the move the data from the CLI.

 

[John Hixson]

is there any way to change an already created dataset's "share type" from UNIX to WINDOWS after it's been created (was created when running 9.2.0. while now i'm at 9.2.1.1). just curious since its greyed out when looking at the dataset's permissions in the GUI.

Click 'Windows/Mac' in the permissions wizard for the dataset. You can do a recursive permission reset at that point, but if you do, know that you are resetting every single file and directory permission to the windows default.