FreeNAS 9.2.1.2-RELEASE is now available

[kozobp]

Hi,

I've posted somehow the same at 9.2.1.1 release. So again, thanks a lot for the developers' efforts!
However, PLEASE, help me!!! I am not able to upgrade my running 9.2.1. to 9.2.1.1 or .2! When I upload my configuration, freenas reboots 2 times, but after, it DOES NOT WORK! No gui, no CIFS, but SSH works. There's a bug 4321 with this issue, I also posted there. I am not the only one having this problem. I've tried GUI update and virgin install, does not work. I can send whatever is needed to find out what the problem is, but please, give me hints what. I am quite noob...

Thanks a lot in advance!

 

[abd]

did this update and now i cant access my network shares

 

[joeschmuck]

However, PLEASE, help me!!! I am not able to upgrade my running 9.2.1. to 9.2.1.1 or .2! When I upload my configuration

Did you read the users guide on how to upgrade or any of the issue with 9.1.1.1 ? Why in the world would you upgrade to that version, it's flawed which is why 9.2.1.2 came out, which also has some flaws if you have read this thread. And if you have gone through the users guide and still can't figure it out, please be very descriptive with what you are doing so we can offer assistance. Also you did make a backup of your 9.2.1 configuration file it sounds like so my first recommendation is to reload 9.2.1 and load up your configuration so your NAS is functional again.

 

[joeschmuck]

did this update and now i cant access my network shares

And? Are you just complaining about it or do you want something? See my previous posting, it applies to your too if you are looking for assistance.

 

[kozobp]

Did you read the users guide on how to upgrade or any of the issue with 9.1.1.1 ? Why in the world would you upgrade to that version, it's flawed which is why 9.2.1.2 came out, which also has some flaws if you have read this thread. And if you have gone through the users guide and still can't figure it out, please be very descriptive with what you are doing so we can offer assistance. Also you did make a backup of your 9.2.1 configuration file it sounds like so my first recommendation is to reload 9.2.1 and load up your configuration so your NAS is functional again.

First, thanks for the answer! I've read the release notes, some forum and bug posts before I typed here... I tried to apply 9.2.1.1 upgrade when it was out, later 9.2.1.2. I write down what I did with both, with the same result. I have 9.2.1 installed originally, I followed the GUI backup steps 1-by-1, so I saved my configuration on my pc. The update was well, however, after the 2nd reboot freenas started, I could log in via SSH, but there was no GUI anymore, and shares also did not work. Then I tried a virgin install from the image. Freenas started OK, then I uploaded my config file. After the second boot the same happened. For sure, I could step back to 9.2.1, so at the moment I am fine. By the way, I use the followings: UFS (due to quite small amount of RAM), CIFS, NFS, miniDLNA, rsync, some cron jobs and I've a jail running a lighttpd+php+mysql. The system runs on a 2GB stick. That's all.

If I missed something out during my forum/bug/release note reading I am sorry wasting your time, or if I don't understand something well. Just I did exactly what is written down, and cannot update. For more details to share, please give me some hints. Finally, I'd like to support development, if my issue is really a bug.

 

[joeschmuck]

I'm not trying to point the finger at low RAM quantity but I do recall reading someone else had an upgrade issue and it was thought to be specifically due to low RAM. I honestly don't know why that would make a difference but... My current advice is if you are unable to upgrade you config file, submit a bug report but you need to be very detailed on your system hardware because if the developers cannot reproduce your results then it will be marked an not able to reproduce. If you want to use 9.2.1.2 and cannot upgrade your config, load up 9.2.1.2 and mount your UFS drives and you may need to redo your jails. The last option is to stick with 9.2.1 until 9.2.2 comes out or try one of the nightly builds.

 

[jkh]

Low RAM can indeed affect the proper operation of FreeNAS, both at installation / upgrade time and during "normal operation". The reason being that the FreeNAS GUI and related support processes can often bloat up to a fairly large memory footprint (python is many fine things, but "sparing of resources" is not one of them) and FreeNAS in general is just not tested in configurations < 4GB. There are a number of edge cases in the GUI, and possibly during the upgrade as well, that can cause lower memory configurations to hit the ceiling and since you don't have any swap space during the upgrade process, processes can be rudely shot down by the kernel or otherwise leave things in an inconsistent state (if a sqlite database update is in progress using the django ORM, and the python process hosting the ORM is shot, well, you're left wherever you were in mid-update).

This is why there are several bugs open which request that FreeNAS not even attempt to install or run on low memory systems, but those bugs have gotten hung up on the questions of "how low is too low" and even "how to determine how much memory is usable?" since some PC configurations reserve a fair amount of system memory for other purposes, like video memory or DMA buffers, and others do not. Does 2GB of memory in the system mean 2GB actually *available*? Generally not! If we also just picked a fairly high number, like 4GB, and enforced that, we'd get a lot of complaints from users saying their 3GB systems used to be *just fine* and now we're saying they can't run anymore? WTF??

We can't win.

 

[joeschmuck]

That is true, it's a fight you can never win but at least it's recognized that low RAM is an issue.

 

[Magnus33]

With the price of ram being slow low these days the odds are most are going to have at least 4gb so where do you set the low ram levels?

Never a easy choice.

 

[unca_NAS]

If you restart syslogd you should be able to start your ftp service up.

service -R syslogd + starting FTP from GUI didnt resolve the ftp-not-starting -problem. Same error as before.

Code:

freenas notifier: proftpd not running?
freenas notifier: Starting proftpd.
freenas notifier: freenas.local proftpd[35785]: Fatal: SyslogFacility: unable to open syslog: Operation not permitted on line 10 of '/usr/local/etc/proftpd.conf'
freenas root: /usr/local/etc/rc.d/proftpd: WARNING: failed to start proftpd
freenas notifier: /usr/local/etc/rc.d/proftpd: WARNING: failed to start proftpd

I can live without working ftp-service but some fix at some point would be nice :)

 

[jtt1560]

service -R syslogd + starting FTP from GUI didnt resolve the ftp-not-starting -problem. Same error as before.

Code:

freenas notifier: proftpd not running?
freenas notifier: Starting proftpd.
freenas notifier: freenas.local proftpd[35785]: Fatal: SyslogFacility: unable to open syslog: Operation not permitted on line 10 of '/usr/local/etc/proftpd.conf'
freenas root: /usr/local/etc/rc.d/proftpd: WARNING: failed to start proftpd
freenas notifier: /usr/local/etc/rc.d/proftpd: WARNING: failed to start proftpd

I can live without working ftp-service but some fix at some point would be nice :)

The problem can be resolved by deselecting "Use system dataset for syslog" in Settings > Advanced.

 

[unca_NAS]

^ That did it! Thanks a bunch!

 

[cyberjock]

This is why there are several bugs open which request that FreeNAS not even attempt to install or run on low memory systems, but those bugs have gotten hung up on the questions of "how low is too low" and even "how to determine how much memory is usable?" since some PC configurations reserve a fair amount of system memory for other purposes, like video memory or DMA buffers, and others do not. Does 2GB of memory in the system mean 2GB actually *available*? Generally not! If we also just picked a fairly high number, like 4GB, and enforced that, we'd get a lot of complaints from users saying their 3GB systems used to be *just fine* and now we're saying they can't run anymore? WTF??

We can't win.

We can absolutely win. Just make it the same as what we call for in the manual as minimum requirements. If they want to upgrade, they can ALWAYS do an ISO install. They can still write a new image and then do a config update. But why not give them an incentive to hit the minimum requirements as called for in the manual and leave it at that? I mean, if we say 8GB of RAM minimum and they want to be upset because it won't let them upgrade with 4GB, well f*ck them. We told them 8GB.

And to be honest, setting it 8GB would probably save ALOT of people from losing their pools from these weird out-of-memory kernel panics that eat pools. Every time a new version comes out and people upgrade we get a rash of lost pools with people that had less than the recommended and did an upgrade. Not surprisingly, with each upgrade the system needs slightly more resources, and for a handful of unlucky people, that means that the "upgrade ate their pool".

So I think we're killing multiple birds with 1 stone.

1. Making it less likely they'll continue to use FreeNAS with less than the minimum RAM.
2. Making it more difficult(but not impossible) to upgrade FreeNAS.
3. Making it less likely that we're going to get a rash of lost pools with said update.

I see no loss at all, except for the people that want to argue that their stuff "ran just fine on <8GB". And I see no reason to cater to those people with the overwhelming amount of data that shows that <8GB of RAM is risky. Taking a conservative approach while leaving them with the option of forcing an upgrade through alternate means if they want to take that risk seems like a no-brainer. Especially since you said x86 is dead.

 

[mysticpete]

Hi all

I had the problems associated with 9.2.1 and Upgraded to FreeNAS-9.2.1.2-RELEASE-x64 (002022c)

I have tested the fix by starting from a scratch zero (0) shares for NFS and CIFS, when I started to add the folders I wanted to share I noticed a strange thing in that after the share is added, smbd and winbindd are reloaded, However sharing is not always started again. If you look at the log sometimes access is denied or 192.168.1.71. this is the laptop I am using to remotely to add the shares, I check the FreeNAS access from it and sure enough "no path found" is reported back.
Next share I add and it all works again....

The difference is that each time it fails the following mount point instructions are Not generated

Mar 10 12:28:43 FreeNAS generate_smb4_conf.py: [common.pipesubr:58] Popen()ing: zfs list -H -o mountpoint,name
Mar 10 12:28:43 FreeNAS generate_smb4_conf.py: [common.pipesubr:58] Popen()ing: zfs list -H -o mountpoint

Should I raise a ticket for this?

Mar 10 12:28:44 FreeNAS notifier: Reloading smbd.
Mar 10 12:28:44 FreeNAS notifier: Reloading winbindd.

Mar 10 12:28:55 FreeNAS smbd[45163]: Denied connection from HP-Split.BigPond (192.168.1.71)
Mar 10 12:32:53 FreeNAS smbd[45313]: [2014/03/10 12:32:53.577432, 0] ../source3/lib/access.c:338(allow_access

Code:

Mar 10 12:25:55 FreeNAS notifier: Reloading smbd.
Mar 10 12:25:55 FreeNAS notifier: Reloading winbindd.
Mar 10 12:27:20 FreeNAS generate_smb4_conf.py: [common.pipesubr:58] Popen()ing: zfs list -H -o mountpoint,name
Mar 10 12:27:20 FreeNAS generate_smb4_conf.py: [common.pipesubr:58] Popen()ing: zfs list -H -o mountpoint
Mar 10 12:27:20 FreeNAS last message repeated 6 times
Mar 10 12:27:20 FreeNAS generate_smb4_conf.py: [common.pipesubr:58] Popen()ing: /usr/local/bin/pdbedit -d 0 -i smbpasswd:/tmp/tmpP4BwNQ -e tdbsam:/var/etc/private/passdb.tdb -s /usr/local/etc/smb4.conf
Mar 10 12:27:20 FreeNAS notifier: Performing sanity check on Samba configuration: OK
Mar 10 12:27:20 FreeNAS notifier: Reloading nmbd.
Mar 10 12:27:20 FreeNAS nmbd[28744]: [2014/03/10 12:27:20.921894,  0] ../source3/nmbd/nmbd_workgroupdb.c:276(dump_workgroups)
Mar 10 12:27:20 FreeNAS nmbd[28744]:  dump_workgroups()
Mar 10 12:27:20 FreeNAS nmbd[28744]:    dump workgroup on subnet    192.168.1.4: netmask=  255.255.255.0:
Mar 10 12:27:20 FreeNAS nmbd[28744]:      WORKGROUP(1) current master browser = FREENAS
Mar 10 12:27:20 FreeNAS nmbd[28744]:          FREENAS 40849a23 (FreeNAS Server)
Mar 10 12:27:20 FreeNAS nmbd[28744]:          HP-SPLIT 40011003 ()
Mar 10 12:27:20 FreeNAS nmbd[28744]:          CANON-PRINTER 40000002 (MG6200 series)
Mar 10 12:27:20 FreeNAS notifier: Reloading smbd.
Mar 10 12:27:20 FreeNAS notifier: Reloading winbindd.
Mar 10 12:28:43 FreeNAS generate_smb4_conf.py: [common.pipesubr:58] Popen()ing: zfs list -H -o mountpoint,name
Mar 10 12:28:43 FreeNAS generate_smb4_conf.py: [common.pipesubr:58] Popen()ing: zfs list -H -o mountpoint
Mar 10 12:28:43 FreeNAS last message repeated 7 times
Mar 10 12:28:43 FreeNAS generate_smb4_conf.py: [common.pipesubr:58] Popen()ing: /usr/local/bin/pdbedit -d 0 -i smbpasswd:/tmp/tmpX5PtNz -e tdbsam:/var/etc/private/passdb.tdb -s /usr/local/etc/smb4.conf
Mar 10 12:28:44 FreeNAS notifier: Performing sanity check on Samba configuration: OK
Mar 10 12:28:44 FreeNAS notifier: Reloading nmbd.
Mar 10 12:28:44 FreeNAS nmbd[28744]: [2014/03/10 12:28:44.373675,  0] ../source3/nmbd/nmbd_workgroupdb.c:276(dump_workgroups)
Mar 10 12:28:44 FreeNAS nmbd[28744]:  dump_workgroups()
Mar 10 12:28:44 FreeNAS nmbd[28744]:    dump workgroup on subnet    192.168.1.4: netmask=  255.255.255.0:
Mar 10 12:28:44 FreeNAS nmbd[28744]:      WORKGROUP(1) current master browser = FREENAS
Mar 10 12:28:44 FreeNAS nmbd[28744]:          FREENAS 40849a23 (FreeNAS Server)
Mar 10 12:28:44 FreeNAS nmbd[28744]:          HP-SPLIT 40011003 ()
Mar 10 12:28:44 FreeNAS nmbd[28744]:          CANON-PRINTER 40000002 (MG6200 series)
Mar 10 12:28:44 FreeNAS notifier: Reloading smbd.
Mar 10 12:28:44 FreeNAS notifier: Reloading winbindd.
Mar 10 12:28:55 FreeNAS smbd[45163]: [2014/03/10 12:28:55.962344,  0] ../source3/lib/access.c:338(allow_access)
Mar 10 12:28:55 FreeNAS smbd[45163]:  Denied connection from HP-Split.BigPond (192.168.1.71)
Mar 10 12:28:55 FreeNAS smbd[45163]: [2014/03/10 12:28:55.964435,  0] ../source3/lib/access.c:338(allow_access)
Mar 10 12:28:55 FreeNAS smbd[45163]:  Denied connection from HP-Split.BigPond (192.168.1.71)
Mar 10 12:32:53 FreeNAS smbd[45313]: [2014/03/10 12:32:53.577432,  0] ../source3/lib/access.c:338(allow_access)

 

[joeschmuck]

We can absolutely win. Just make it the same as what we call for in the manual as minimum requirements. If they want to upgrade, they can ALWAYS do an ISO install. They can still write a new image and then do a config update. But why not give them an incentive to hit the minimum requirements as called for in the manual and leave it at that? I mean, if we say 8GB of RAM minimum and they want to be upset because it won't let them upgrade with 4GB, well f*ck them. We told them 8GB.

Have a check during installation to ensure they have at least 7GB RAM because sometimes some resources will lower the available RAM from an 8GB setup. If it's above this check then no warning messages. If below this limit you toss an alert/warning message saying FreeNAS is not supported with less than 8GB RAM, and have them acknowledge it to proceed with installation.

Why do I say just a warning message, because in a VM how are you going to check the RAM amount? Do you really need to give up 8GB RAM for a VM? I know I can but can everyone just to try or test things out.

Just a thought.

 

[TenzoR]

With the price of ram being slow low these days the odds are most are going to have at least 4gb so where do you set the low ram levels?

Never a easy choice.

Actually RAM prices has been going up steadily ...

 

[G Brown]

Seems to be working ok.
Spurious? error messages when renamed snapshots are received, but all seems to work. Upstream issue?
( /sbin/zfs send -v -R -I $src@backup1 $src@backup2 | zfs recv -v -d -F $sink )
Send from rz2 to offsite pool, error messages in red : with verbose:

Code:

>>>freenas: root@/mnt/rz2/data/gb$: ./zfssnapup.sh
Making new snapshot rz2/data@backup3
Deleteing oldest snapshot
Holding this backup snapshot rz2/data@backup3
Renaming the snapshots
Releasing rz2/data@backup.olddelete
Sending the snapshot to offsite
send from @backup1 to rz2/data@auto-20140309.2050-3d estimated size is 0
send from @auto-20140309.2050-3d to rz2/data@auto-20140310.0530-3d estimated size is 0
send from @auto-20140310.0530-3d to rz2/data@backup2 estimated size is 0
send from @backup1 to rz2/data/gb@auto-20140309.2050-3d estimated size is 1.24M
send from @auto-20140309.2050-3d to rz2/data/gb@auto-20140310.0530-3d estimated size is 45.5K
send from @auto-20140310.0530-3d to rz2/data/gb@backup2 estimated size is 0
send from @backup1 to rz2/data/archive@auto-20140309.2050-3d estimated size is 0
send from @auto-20140309.2050-3d to rz2/data/archive@auto-20140310.0530-3d estimated size is 0
send from @auto-20140310.0530-3d to rz2/data/archive@backup2 estimated size is 0
total estimated size is 1.29M
attempting destroy offsite/data@backup.olddelete
TIME        SENT  SNAPSHOT
TIME        SENT  SNAPSHOT
TIME        SENT  SNAPSHOT
TIME        SENT  SNAPSHOT
success
attempting rename offsite/data@backup1 to offsite/data@backup.olddelete
success
attempting rename offsite/data@backup2 to offsite/data@backup1
success
attempting destroy offsite/data/archive@backup.olddelete
09:30:37  58.6K  rz2/data/gb@auto-20140309.2050-3d
success
attempting rename offsite/data/archive@backup1 to offsite/data/archive@backup.olddelete
success
attempting rename offsite/data/archive@backup2 to offsite/data/archive@backup1
success
attempting rename offsite/data/archive to offsite/data/archive
failed - trying rename offsite/data/archive to offsite/data/recv-62908-1
attempting destroy offsite/data/gb@backup.olddelete
success
attempting rename offsite/data/gb@backup1 to offsite/data/gb@backup.olddelete
success
attempting rename offsite/data/gb@backup2 to offsite/data/gb@backup1
09:30:38  58.6K  rz2/data/gb@auto-20140309.2050-3d
success
attempting rename offsite/data/gb to offsite/data/gb
failed - trying rename offsite/data/gb to offsite/data/recv-62908-2
another pass:
attempting rename offsite/data/recv-62908-2 to offsite/data/gb
success
attempting rename offsite/data/recv-62908-1 to offsite/data/archive
success
cannot open 'offsite/data/recv-62908-1': dataset does not exist
cannot open 'offsite/data/recv-62908-2': dataset does not exist
receiving incremental stream of rz2/data@auto-20140309.2050-3d into offsite/data@auto-20140309.2050-3d
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of rz2/data@auto-20140310.0530-3d into offsite/data@auto-20140310.0530-3d
09:30:39  58.6K  rz2/data/gb@auto-20140309.2050-3d
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of rz2/data@backup2 into offsite/data@backup2
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of rz2/data/gb@auto-20140309.2050-3d into offsite/data/gb@auto-20140309.2050-3d
TIME        SENT  SNAPSHOT
TIME        SENT  SNAPSHOT
TIME        SENT  SNAPSHOT
TIME        SENT  SNAPSHOT
TIME        SENT  SNAPSHOT
received 1.26MB stream in 1 seconds (1.26MB/sec)
receiving incremental stream of rz2/data/gb@auto-20140310.0530-3d into offsite/data/gb@auto-20140310.0530-3d
received 19.6KB stream in 1 seconds (19.6KB/sec)
receiving incremental stream of rz2/data/gb@backup2 into offsite/data/gb@backup2
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of rz2/data/archive@auto-20140309.2050-3d into offsite/data/archive@auto-20140309.2050-3d
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of rz2/data/archive@auto-20140310.0530-3d into offsite/data/archive@auto-20140310.0530-3d
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of rz2/data/archive@backup2 into offsite/data/archive@backup2
received 312B stream in 1 seconds (312B/sec)

 

[indy]

Is there a known problem with new CIFS files not inheriting their parent directory's permission even though the option is enabled in the share options?
I could not find a bug filed for it - could be user error as well however :)

 

[DoubleIPA]

I do not see a GUI upgrade for 9.2.1.2 x64 only the 32bit. Is this supposed to be the case?

 

[gpsguy]

You can download the file at: download.freenas.org


Sent from my phone