FreeNAS 9.2.1.6-BETA is now available

[Craig Rodrigues]

FreeNAS 9.2.1.6-BETA is available here.

All bugs fixed in FreeNAS 9.2.1.6-BETA can be found here.

The major items of interest are mentioned in the ReleaseNotes here.
These items include:

• Samba is updated to 4.1.8
• Netatalk is updated to 3.1.2
• Several fixes related to the System Dataset
• A new VirtualBox jail template
• Several fixes related to ZFS replication
• A new mpr driver, officially sanctioned by LSI, for the LSI 12 Gbps SAS HBA
• An experimental in-kernel iSCSI target
• A .usb file which can be imaged to a USB key. This can be used for installing FreeNAS from a USB key.

Please provide feedback on this BETA. If no major problems are found, we will release 9.2.1.6-RELEASE in approximately 14 days.

Thank you for testing FreeNAS!

- The FreeNAS Development Team

 

[Sir.Robin]

Great work! :)

 

[Scareh]

verry nice! thanks for the effort beta testers

 

[solarisguy]

I think https://bugs.freenas.org/issues/5173 should be mentioned here and in the ReleaseNotes for BETA.

That is, if your CIFS is not as fast as it were, you may want to change Server maximum protocol: to SMB2 in Services/CIFS

 

[jkh]

I think https://bugs.freenas.org/issues/5173 should be mentioned here and in the ReleaseNotes for BETA

Well, it's hard to edit the ReleaseNotes post-facto unless you also want the release notes to be out of sync with the 9.2.1.6-BETA tag (the 9.2.1.6-BETA horse is already out of the barn, in other words!) but it looks like John just figured out why the new default of SMB2 didn't take, and this will be verified as actually working before the 9.2.1.6-RC (Release Candidate) goes out.

 

[beberobu]

Auch, and the bug 5098 (ftp dont work correctly)..... :(

 

[aufalien]

Rockin!

Stoked about this, awesome work FreeNAS/IX!

 

[Joshua Parker Ruehlig]

I guess I'll ask... what's next 9.2.2, 9.3, or 10? if it's 9.3 would it be have to wait till freebsd 9.3? any estimate when 10.X will be the target?

thanks freenas team for the vigilant bug fix/new feature releases!

 

[aufalien]

That's an interesting question as based on the nightlies download arra (not nightly), they've done away with 9.2.2 and have 9.3 instead.

http://download.freenas.org/nightlies/

I couldn't find a roadmap/feature list for 9.3 or 10 which would be cool.

 

[Ericloewe]

I guess I'll ask... what's next 9.2.2, 9.3, or 10? if it's 9.3 would it be have to wait till freebsd 9.3? any estimate when 10.X will be the target?

thanks freenas team for the vigilant bug fix/new feature releases!

9.2.2 was renamed 9.3 because it was decided it would be based on FreeBSD 9.3, because the tentative release date allowed that.

 

[scotch_tape]

JKH/Craig, is the SMB problem with the code coming out of samba.org or with the integration of that code into FreeNAS?

 

[jkh]

JKH/Craig, is the SMB problem with the code coming out of samba.org or with the integration of that code into FreeNAS?

samba.org. We also encourage folks to keep filing tickets against the samba.org bug tracker, particularly when smb panics or emits weird log messages that can help the Samba project to improve it.

 

[Yatti420]

So this is the official 1st released beta? Let's not skip the RC when the time comes..

 

[gearhead]

I am getting the following message. Should I be concerned?
Jun 15 18:25:24 freenas smbd[15774]: [2014/06/15 18:25:24.755332, 0] ../lib/util/talloc_stack.c:104(talloc_pop)
Jun 15 18:25:24 freenas smbd[15774]: Freed frame ../source3/smbd/process.c:3692, expected ../source3/modules/nfs4_acls.c:936.

 

[G Brown]

With the imminent release of FreeNAS 9.2.1.6, it is time to think about the best way to upgrade from previous versions. There has been a lot of changes in the filesharing software versions and set up parameters.

Most of the data sets that will be upgraded were not created with the new release. I haven't seen any documentation--yet--about what those shared--type create–data--set options actually do.

Q1: What parameters are manipulated with each of these create data set share type options?

Q2: Is it possible to switch the data set parameters in order to change a CIFS/Windows type data set into an Apple type data set? How? What parameters need to be changed?

Q3: In the web browser, storage tab, pop-up window from edit ZFS data set; how is that value for shared type determined? Does the GUI dynamically read various parameters and make a best guess?

Q4: Is it best to make sure that the various parameters are set to the correct profile prior to upgrading, or, does the upgrade process examine and change any of these parameters?

And on a crazy note, NETATALK says the following:

the format of the ._ file is exactly as the Mac’s CIFS client expects it when accessing the same filesystem via a CIFS server (Samba), thus you can have parallel access from Macs to the same dataset via AFP and CIFS without the risk of loosing data (resources or metadata).

So it would seem that it would be possible to share the same data set with NETATALK and SAMBA, if SAMBA had extended attributes turned off and used the Appledouble metadata format. Has anybody successfully done this? I know, it's probably crazy, as it is hard enough to just get either one working reliably. It is just that in the future SAMBA will probably be the only protocol we need, but right now both are needed.

tia

 

[cyberjock]

G Brown:

Standby bro. I'm working on just a document that will answer many of your question(but not all).

Some of them are already answered in the manual. For example, you shouldn't share the same data with more than 1 protocol to prevent file corruption. There is not and will most likely never be a fix for this problem. This is not a FreeNAS problem but is a problem with servers running multiple protocols.

 

[jkh]

Q1: What parameters are manipulated with each of these create data set share type options?

That's deliberately hidden as an implementation detail, since we reserve the right to change it as experience and best practices dictate. If you're really motivated to find out, the source code is generally available. :)

Q2: Is it possible to switch the data set parameters in order to change a CIFS/Windows type data set into an Apple type data set? How? What parameters need to be changed?

Not currently, no. This is a creation-time attribute.

Q3: In the web browser, storage tab, pop-up window from edit ZFS data set; how is that value for shared type determined? Does the GUI dynamically read various parameters and make a best guess?

Not sure I understand this question.

Q4: Is it best to make sure that the various parameters are set to the correct profile prior to upgrading, or, does the upgrade process examine and change any of these parameters?

Kind of the opposite - it's best to make sure that the various parameters are set correctly *after* upgrading, since upgrades tends to preserve the old preferences (because that's just how upgrades work) and you need to check after the upgrade to see if you've carried an old option forward.

the format of the ._ file is exactly as the Mac’s CIFS client expects it when accessing the same filesystem via a CIFS server (Samba), thus you can have parallel access from Macs to the same dataset via AFP and CIFS without the risk of loosing data (resources or metadata).

While that is technically true, what is not being said here is the fact that smbd, netatalk and nfsd are all separate user-land services and do not implement things like locking semantics the same way, so if you run multiple share types from a single dataset, it's not clear that one will not go behind the back of another. Let's say that NFS flock()s a file a client is working on, but Samba comes along and says "I will use Windows oplocks, because that is how Windows rolls!", you could have a locked file changed out from under you (a lock type can be advisory, it doesn't necessarily have to prevent other things from ignoring the advice and opening things read/write).

This could be potentially changed some day if we implemented a single distributed lock manager on FreeNAS and had all of the various sharing services coordinate their operations through it, but that is a pipe dream for the future. We just don't have enough engineering resources available to make all of the relevant changes that would be necessary (and maintain those changes indefinitely in projects like samba and netatalk), so for now the rule is "one dataset, one sharing type".

 

[solarisguy]

I know that on FreeBSD sharesmb property is not implemented yet. But in general, I was under the impression that OpenZFS would allow both NFS (via sharenfs) and SMB protocols to be enabled at the same time for the same share?

 

[jpaetzel]

Yes, but solaris has their own SMB server and it shares a locking model with their NFS server. FreeNAS not so much.

 

[G Brown]

That's deliberately hidden as an implementation detail, since we reserve the right to change it as experience and best practices dictate. If you're really motivated to find out, the source code is generally available. :)
Not currently, no. This is a creation-time attribute.
...
Kind of the opposite - it's best to make sure that the various parameters are set correctly *after* upgrading, since upgrades tends to preserve the old preferences (because that's just how upgrades work) and you need to check after the upgrade to see if you've carried an old option forward.

OK this part of gui/middleware/notifier.py is new, and shows default permissions.

Code:

    def dataset_init_unix(self, dataset):
        """path = "/mnt/%s" % dataset"""
        pass
 
    def dataset_init_windows(self, dataset):
        acl = [
            "owner@:rwxpDdaARWcCos:fd:allow",
            "group@:rwxpDdaARWcCos:fd:allow",
            "everyone@:rxaRc:fd:allow"
        ]
 
        path = "/mnt/%s" % dataset
        with open("%s/.windows" % path, "w") as f:
            f.close()
 
        for ace in acl:
            self._pipeopen("/bin/setfacl -m '%s' '%s'" % (ace, path)).wait()
 
    def dataset_init_apple(self, dataset):
        path = "/mnt/%s" % dataset
        with open("%s/.apple" % path, "w") as f:
            f.close()
 
    def get_dataset_share_type(self, dataset):
        share_type = "unix"
 
        path = "/mnt/%s" % dataset
        if os.path.exists("%s/.windows" % path):
            share_type = "windows"
        elif os.path.exists("%s/.windows" % path):
            share_type = "apple"
 
        return share_type

It seems like most of the changes have been for a Windows share, and Apple and UNIX shares have few changes.

I suppose that users can, after the upgrade, create a test window share, and Apple share, and a UNIX share, and compare the permissions, ZFS parameters, etc. and align their old data sets to the parameters of the newly created data sets.

For instance, my existing data set files have permissions like the following:

Code:

# file: notifier.pySNIPPET
# owner: gb
# group: gb
            owner@:rwxp--aARWcCos:------:allow
            group@:r-x---a-R-c--s:------:allow
        everyone@:r-x---a-R-c--s:------:allow

These are somewhat different. How significant that is, I'm not sure.

By the way, doesn't this code:

Code:

        if os.path.exists("%s/.windows" % path):
            share_type = "windows"
        elif os.path.exists("%s/.windows" % path):
            share_type = "apple"

Only test for a ".windows" file ? Is that a copy/paste gone bad? Not familiar with Python.

This dataset type stuff is new, and there is always the issue of what kind of shape people will be in after upgrading an old dataset, and how do they tell? Cyberjock will probably finish writing his document on this as soon as I hit post.

I/we/you will be grateful when the 9.2 branch is finished!

Thanks, and onto....9.3? we hope...