Announcing FreeNAS 9.2.1-RELEASE

[Savell Martin]

Anyone?

 

[jkh]

I have the opportunity to move my data off my FreeNAS server (as im still in the process of setting it up).
My question is, would it be better to download and do a totally clean install of 9.2.1 rather than upgrading from 9.2?
As in re-create new clean volumes and everything with the new Release?

Or is there no difference with upgrading?

No difference with upgrading.

 

[jgreco]

Oh. My. God.

I am mostly totally blown away. I've been battling latency and crappy I/O scheduling in ZFS for quite a while. I put the new 9.2.1 (had 9.1.1 on it) on the big slow archival filer here and it approximately doubled in speed, and I had very great difficulty convincing it to burp at me. It used to scrub at about 320MB/sec. Now doing 611MB/sec - and still has great interactive response.

 

[briffle]

I am affected by the CIFS bug: https://bugs.freenas.org/issues/4151 However, I tried to register for the bug tracker, and I can't log in, because of "invalid username or password" but can't send a reminder, since it can't find my email address, but trying to re-register, the email and username are both already taken.

However, I have wanted to try update #5 in the bug, but according to: http://doc.freenas.org/index.php/Windows_(CIFS)_Shares I should not change the inherit permissions with the ACL set to windows/mac on the volume. Is there another step (or config option) I can try setting? Our mac users have had a heck of a lot of very weird problems with 9.2.0 (and the older versions) using things like indesign right over the network, and I was hoping some of the fixes in here would fix it. (I had to disable streams on the individual mac's themselves before, and things got much better, but still some weird things that are hard to reproduce.

 

[Savell Martin]

Can anyone help with this?
Is it a bug should I file it or is it expected?

Just I get it all day every day:

Feb 13 08:18:44 freenas smbd[56971]: [2014/02/13 08:18:44.136704, 0] ../source3/lib/util_sock.c:941(matchname)
Feb 13 08:18:44 freenas smbd[56971]: matchname: host name/name mismatch: 192.168.1.8 != (NULL)
Feb 13 08:18:44 freenas smbd[56971]: [2014/02/13 08:18:44.136745, 0] ../source3/lib/util_sock.c:1199(get_remote_hostname)
Feb 13 08:18:44 freenas smbd[56971]: matchname failed on 192.168.1.8
Feb 13 08:24:14 freenas smbd[57212]: [2014/02/13 08:24:14.128032, 0] ../source3/lib/util_sock.c:941(matchname)
Feb 13 08:24:14 freenas smbd[57212]: matchname: host name/name mismatch: 192.168.1.17 != (NULL)
Feb 13 08:24:14 freenas smbd[57212]: [2014/02/13 08:24:14.128131, 0] ../source3/lib/util_sock.c:1199(get_remote_hostname)
Feb 13 08:24:14 freenas smbd[57212]: matchname failed on 192.168.1.17

 

[djonik1562]

Can anyone help with this?
Is it a bug should I file it or is it expected?

Just I get it all day every day:

Feb 13 08:18:44 freenas smbd[56971]: [2014/02/13 08:18:44.136704, 0] ../source3/lib/util_sock.c:941(matchname)
Feb 13 08:18:44 freenas smbd[56971]: matchname: host name/name mismatch: 192.168.1.8 != (NULL)
Feb 13 08:18:44 freenas smbd[56971]: [2014/02/13 08:18:44.136745, 0] ../source3/lib/util_sock.c:1199(get_remote_hostname)
Feb 13 08:18:44 freenas smbd[56971]: matchname failed on 192.168.1.8
Feb 13 08:24:14 freenas smbd[57212]: [2014/02/13 08:24:14.128032, 0] ../source3/lib/util_sock.c:941(matchname)
Feb 13 08:24:14 freenas smbd[57212]: matchname: host name/name mismatch: 192.168.1.17 != (NULL)
Feb 13 08:24:14 freenas smbd[57212]: [2014/02/13 08:24:14.128131, 0] ../source3/lib/util_sock.c:1199(get_remote_hostname)
Feb 13 08:24:14 freenas smbd[57212]: matchname failed on 192.168.1.17

I after update unselected this option on CIFS, restrat freenas and laptop. And good work.

 

[Savell Martin]

Thanks :)

 

[dilbert2011]

Thanks - I was also stuck with same repeating matchname error after upgrade and this advice stopped it.

 

[Mguilicutty]

For anyone who needs the v16 firmware for their Supermicro's onboard 2308, here is the link. Also, any Supermicro LSI firmware can be found there by clicking around a bit.

ftp://ftp.supermicro.com/driver/SAS/LSI/2308/Firmware/IT/

 

[Savell Martin]

Does 9.2.1.1 have an eta?

 

[cyberjock]

Yep.. it's started already. ETAs. It'll be out when its out! We keep saying that, and everyone keeps asking anyway... LOL.

 

[Savell Martin]

Gotta ask :D

 

[dfsooner]

I would really like to try 9.2.1 but the CIFS read-only problems are scaring me off.

 

[Savell Martin]

dfsooner, I would personally hold off.

 

[GaiusBaltar]

I would really like to try 9.2.1 but the CIFS read-only problems are scaring me off.

it's due to SAMBA4 and ACLs. there's already a workaround in the bug ticket. I implimented it on my system and now no longer have the issue:
check out posts #17 and #25
https://bugs.freenas.org/issues/4151

To update permissions recursively for folders:

Code:

find /mnt/path_to_share/ -type d -exec setfacl -m owner@:full_set:fd:allow,group@:modify_set:fd:allow {} \;

and for files:

Code:

find /mnt/path_to_share/ -type f -exec setfacl -m owner@:full_set::allow,group@:modify_set::allow {} \;

i only ran the command for permissions recursively for folders. i did not have a need to run it for my files. after that, i had the access and rights required for my needs.

 

[dfsooner]

As a lifelong Windows guy, I'm still not comfortable with the Unix-like command line instructions. I think I'll just wait until it's fixed. It's not that I couldn't figure it out. It's just that I have 100 TB or so of data at risk and I don't want to jeopardize that by mistyping or misunderstanding a parameter.

 

[Milkwerm]

Well i notice that all the 9.2.1.1 bug reports are now closed on the freenas redmine page https://bugs.freenas.org :)
So it cant be too far away..

 

[jkh]

Indeed. It's there now! :)

 

[jyavenard]

it's due to SAMBA4 and ACLs. there's already a workaround in the bug ticket. I implimented it on my system and now no longer have the issue:
check out posts #17 and #25
https://bugs.freenas.org/issues/4151

To update permissions recursively for folders:

Code:

find /mnt/path_to_share/ -type d -exec setfacl -m owner@:full_set:fd:allow,group@:modify_set:fd:allow {} \;

and for files:

Code:

find /mnt/path_to_share/ -type f -exec setfacl -m owner@:full_set::allow,group@:modify_set::allow {} \;

i only ran the command for permissions recursively for folders. i did not have a need to run it for my files. after that, i had the access and rights required for my needs.

IMHO, when you create a dataset in the GUI, assign it an owner and group, then just create a share of that drive it should just work as the user intended.

Not have to fire a command line and manually play with the ACL

 

[GaiusBaltar]

IMHO, when you create a dataset in the GUI, assign it an owner and group, then just create a share of that drive it should just work as the user intended.

Not have to fire a command line and manually play with the ACL

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:

Updated by John Hixson about 18 hours ago

• Status changed from Investigation to Behaves correctly

So, everyone that is following this ticket: samba4 is more finicky about ACL's then previous versions were. Several people have posted how to address this issue moving forward. It is unfortunate that this came about, but there are workarounds. Moving forward, default ACL's that are reasonable have been committed to FreeNAS and will be available in 9.2.1.1. I consider this ticket as "behaves correctly". For any of you that are having this issue, please read the ticket in full for the various methods to address this issue. It's not really a "bug", just "changed behavior".