Everything opens as "Read Only"

[CLSegraves]

Installed 9.2.1.3. Samba (and therefore CIFS) is still broken. To make matters even more frustrating, now I can't see the NAS over NFS. Still have access through the web portal and can see the box through my router. errrr....

 

[solarisguy]

Clearly you are doing something that either tickles a bug in the newest versions of Samba or requires a very special treatment of Samba/CIFS setup.

The versions of Samba in recent FreeNAS releases are as follows:

• 9.1.0 has samba 3.6.12
• 9.1.1 has samba 3.6.12(?)
• 9.2.0 has samba 3.6.21
• 9.2.1 has samba 4.1.3 (Samba 4.x brought in lots of changes)
• 9.2.1.1 has samba 4.1.4 (“with select key fixes cherry-picked from 4.1.5”)
• 9.2.1.2 has samba 4.1.5
• 9.2.1.3 has samba 4.1.6
• 9.2.1.4 has samba 4.1.6
• 9.2.1.5 has samba 4.1.6, CIFS needs a patch to work
• 9.2.1.6 has samba 4.1.7 (the newest Samba version available for now, released on the 17th of April 2014)

Since 9.1.0 works for you, then 9.2.0 would most likely also work (I would just run it from USB memory).

I am not a FreeNAS developer, but in my opinion your setup must be an interesting one...
* Maybe something should be added to FreeNAS documentation...
* Maybe something should be changed in FreeNAS...
* Maybe when talking to Samba 4.x a small adjustment on your Windows client(s) is all what it would take... (I know that you are running OK now, but before that, did you try on your Windows machine to execute in a command window net view \\FreeNAS_IP ?)

 

[CLSegraves]

I installed 9.2.0 this evening and immediately could access the NAS through CIFS. So, 9.2.0 (with Samba 3.6) seems to be the solution. HOWEVER, now I'm faced with the issue of how to mount my ZFS drives that were made in 9.2.1 (with Samba 4.1). When I try to auto import my ZFS drives, the system gives an error (can't auto import).

 

[CLSegraves]

So for giggles, I upgraded to 9.2.1 to see if I might luck out and keep CIFS working while being able to import the ZFS drives. No luck. Drives import fine, but CIFS is broken. So it seems there is no way to make Samba 4.1 work. What can I do to get the data off of the ZFS drives so I can do a total rebuild to 9.2.0?

 

[jkh]

I installed 9.2.0 this evening and immediately could access the NAS through CIFS. So, 9.2.0 (with Samba 3.6) seems to be the solution.

We have yet to run into a CIFS scenario that couldn't be addressed by proper use of ACLs. The issues crop up when someone tries to mix Unix permissions with ACLs (particularly when they apply the Unix permissions *after* applying the ACLs) since, as we have determined, things like chmod(2) actually strip certain ACLs right off the files and directories (Inherit, Delete, Delete Child for example) and this happens with both UFS and ZFS.

We're still trying to figure out why this behavior was implemented in FreeBSD in the first place, since it seems like pretty lossy behavior, but there is an easy way around it for the moment - DON'T DO THAT. Use the Windows / Mac ACL type (with Apply Recursively checked) in the Dataset permissions UI, then use Windows to set the more advanced ACLs and don't use chown/chgrp/chmod from the Unix side, since those will destroy your ACLs.

Also, don't share the same dataset via NFS and CIFS unless you are also prepared to use NFSv4 ACLs on the client side. Windows and traditional Unix permissions are simply not the same things, they don't play nice together, and at least ACLs have standardized the relationship somewhat.

 

[CLSegraves]

I'm currently in the process of getting all of the data off the NAS so I can rebuild to 9.2.0. This "enjoyable" experience has brought home the need for a better backup system than what I have (ie: none....).

In order to have something I can backup from (ie: the issue with this NAS was not data loss but needed to be rolled back), I'd need a second NAS just sitting there as a data holder. If I just had an external HDD mounted on the current NAS, I would have faced the same issue I currently have (it wouldn't mount on the 9.2.0 build, so I still couldn't access the data to rebuild). It has to be entirely separate so I could rebuild, then fetch the data from the "backup" machine.

I'm currently using socket 775 stuff on my NAS (actually all of my home PCs are 775) because I have not seen a reason to upgrade. Is there any major advantage to going to a newer socket (such as the 1155)? Certainly they could be "faster" but the 775 has been working fine and they are dirt cheap. I was thinking of upgrading the "main" NAS to use a Supermicro X9S socket 775 board, then using the current Asus board in the backup unit.

 

[solarisguy]

Regardless of your decision, two words: ECC RAM. I personally tend to buy newer models (Intel often lists EOL date) due to ability to get exact replacements during the lifetime of a system.

Now, back to your real issue. Theoretically FreeNAS 9.2.0 should be able to read pool created by later revisions of FreeNAS... That was the advantage of feature flags. FreeNAS 9.2.1 added the following features: enabled_txg, hole_birth, extensible_dataset, bookmarks.

If you could test something please...

1. on FreeNAS 9.2.0 try to import read-only, from the command line zpool import -o readonly=on YOUR_POOL_NAME
2. on FreeNAS 9.2.1 set the new features to disabled, then try to import on 9.2.0:

• zpool set enabled_txg=disabled YOUR_POOL_NAME
• zpool set hole_birth=disabled YOUR_POOL_NAME
• zpool set extensible_dataset=disabled YOUR_POOL_NAME
• zpool set bookmarks=disabled YOUR_POOL_NAME

According to the documentation :D the first step should just work ;)

 

[CLSegraves]

I'll give it a shot. Right now I'm copying all of the data from the NAS to an external drive so I don't loose anything.

So let me see if I understand correctly. I'll roll back to 9.2.0, then via SSH, try to import the pools with the command zpool import -o readonly=on YOUR_POOL_NAME

What do I gain from rolling forward to 9.2.1? I'm a bit reluctant to move forward again after all the frustration of this weekend, so want to make sure it's worth the trouble.

 

[solarisguy]

Yes, you understood correctly.

Well ;) if you can go past 9.2.0, then you are getting better Samba (if you can make it work****) and better ZFS internals (and lots of bug fixes if you end at 9.2.1.6).

**** What exactly are your client systems? Linux? Unix? Windows?

 

[CLSegraves]

All client systems are Windows. They are all home PCs (my computer, the wife's PC, the HTPC, etc.). We use our NAS as a central storage location for documents, pictures, videos, etc. so anyone can get to them from any of our home computers.

 

[CLSegraves]

Okay, I rolled back to 9.2.0, did a full reset, started CIFS and I can see my box.

Then I tried:

zpool import -o readonly=on DocsDrive

and got the following:

This pool uses the following feature(s) not supported by this system:

com.delphix:hole_birth​

cannot import 'DocsDrive': unsupported version or feature

soooooo.... ideas?

I'll give option #2 (loading everything in 9.2.1 and disabling hole_birth) and see if that works.

 

[cyberjock]

Yep.. you did a zpool upgrade. You must use 9.2.1+ now.

Oh, and you can't disable a feature flag after it's been enabled. Once enabled always enabled. So you are still stuck with 9.2.1+ forever.

From the FreeNAS docs....

The ZFS upgrade procedure is non-reversible. Do not upgrade your ZFS version unless you are absolutely sure that you will never want to go back to the previous version. There is no reversing a ZFS pool upgrade, and there is no way for a system with an older version of ZFS to access pools that have been upgraded.

 

[CLSegraves]

So in short, I'm stuck doing a full rebuild (including destroying the ZFS) to 9.2.0.

 

[cyberjock]

If you *must* go back to 9.2.0, yes.

 

[CLSegraves]

For whatever reason, I CAN NOT get anything after 9.2.0 to show up in either windows CIFS or NFS. I "can" get the the NAS through a standalone NFS client, however it's a pain to access the stuff (can't just mount and access the drives like normal).

 

[CLSegraves]

I gave option #2 a shot and here is what I got:

zpool set enable_txg=disabled DocsDrive
cannot set property for 'DocsDrive': invalid property 'enable_txg'

and the same result for all others.

So (does everyone agree?) it seems these options cannot be turned off.

 

[cyberjock]

So (does everyone agree?) it seems these options cannot be turned off.

I said that above...

Oh, and you can't disable a feature flag after it's been enabled. Once enabled always enabled.

 

[solarisguy]

I am almost in the agreement with cyberjock arguments****. However..., dear CLSegraves, please try (one last time) on FreeNAS 9.2.1
zpool set com.delphix:hole_birth=disabled DocsDrive
earlier you had tried only zpool set hole_birth=disabled DocsDrive


**** CLSegraves's pool version is 5000, so unless 9.2.0 has a version 1000, he should be OK to import read-only. This is how ZFS features are supposed to work...

 

[cyberjock]

Sigh... really? Check this out.. see that com.delphix stuff.. delphix is one of the ZFS developers(used to be part of FreeNAS too!) and wrote this presentation...


http://blog.delphix.com/csiden/files/2012/01/ZFS_Feature_Flags.pdf

And from that presentation:

The only value administrators can set is "enabled". Features cannot be set to "disabled" once enabled

I've been here and tried it and it definitely, for 100% certainty does NOT work.

Not to sound harsh at anyone, but I don't comment on stuff unless I know for certain that I have the answer and that it is correct. Yes, sometimes things change, but this is a fundamental limitation of ZFS and the developers have already said that there is no chance this behavior will ever change without a mind boggling amount of resources being spent on it.

 

[solarisguy]

I'm wrong, I'm wrong... And reading wrong documentation, too...

Wrong on so many counts..., CLSegraves I'm so sorry!