NAS4Free 11.1.0.4.5127 released (FreeBSD 11.1-RELEASE-P6)

[zoon01]

Warning: if you use thebrig, OBI or other stuff that use PHP, please do not upgrade until extensions are updated to support latest PHP 7.2.x or disable those extensions before upgrade!

The NAS4Free Team is pleased to announce the release of version 11.1.0.4.5127 - Atomics

Download build 11.1.0.4.5127
Please Read always the readme_11.1 file

BUILD 11.1.0.4.5127

Changes after release 11.1.0.4.5109
===============================
- WebGUI code & framework improvements.
- Upgrade gzip to 1.9.
- Upgrade syncthing to 0.14.44.
- Fix transmission starting.
- Fix bug in email setup.
- Fix remove geli flags before deleting a geli device.

Note:
Clear your browser's cache to avoid display issues after upgrade when coming from older release like past 11.0 series.
Make a new backup of your system configuration and store this on safe location, the system config.xml has been upgraded!

Enjoy!

Regards,
The NAS4Free Team

[jamaroney]

All works fine for me, including transmission - thanks!

[netware5]

Updated successfully from 5019.

[lux]

updated from r5065 without any Problem!

THX to all Dev's!

[mooblie]

Upgrade with no problems on two elderly HP Microservers: N36L and N40L.

AFP read speeds went from 96MB/s up to 108MB/s - practically saturating Gigabit Ethernet on a lowly N36L !

Many thanks to all concerned!!

[vicmarto]

Hello,

Just upgraded the Nic of my NAS4Free to a 10Gbe Intel X540-T1 but... Autoselect configures it as 1000baseT, and can't force 10Gbe in the web, please, check attached capture.

Is this normal?

[raulfg3]

Hello,

Just upgraded the Nic of my NAS4Free to a 10Gbe Intel X540-T1 but... Autoselect configures it as 1000baseT, and can't force 10Gbe in the web, please, check attached capture.

Is this normal?

No, but first revise cable, most of the times is a bad cable that do not support expected speed ( I suffer this with a cat5 cable that do not work at 1000 only at 100 MB, once change the cable to cat6, I have 1000 MB).

PD: Check switch too, not only NIC and cable must be 10GB

[vicmarto]

Hello,

Just upgraded the Nic of my NAS4Free to a 10Gbe Intel X540-T1 but... Autoselect configures it as 1000baseT, and can't force 10Gbe in the web, please, check attached capture.

Is this normal?

No, but first revise cable, most of the times is a bad cable that do not support expected speed ( I suffer this with a cat5 cable that do not work at 1000 only at 100 MB, once change the cable to cat6, I have 1000 MB).

PD: Check switch too, not only NIC and cable must be 10GB

Thanks for reply raulfg3.

Have tried with another cable (this one cat.7, the other one was cat.6a) and same happens! But, it's strange, because 10Gbe can't be selected in the web interface, but ifconfig says it's connected as 10Gbe (and transfer speed confirms it):

Code: Select all

	ix0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=e407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
	ether ---------------
	hwaddr -------------
	inet 10.0.0.1 netmask 0x80000000 broadcast 127.255.255.255 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect (10Gbase-T <full-duplex,rxpause,txpause>)
	status: active

No switch, it's a direct connection between 2 computers. ifconfig of the other computer:

Code: Select all

	en5: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=67<RXCSUM,TXCSUM,VLAN_MTU,TSO4,TSO6>
	ether  ---------------
	inet6 fe80::14f3:377f:7a60:c085%en5 prefixlen 64 secured scopeid 0x6 
	inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect (10GbaseT <full-duplex,flow-control>)
	status: active

It's really strange, what can be?

[ms49434]

The options displayed in the WebGUI are usually not required because autoselect is the preferred option. Each driver comes with a specific set of supported media types which can be queried via

Code: Select all

ifconfig -m [interface name]

If you want to force a specific media type that isn't listed you should look into adding parameter into the extra option field on the interface page, read the ifconfig manual and the driver documentation.

[Onichan]

Windows Previous versions broke again, same permission issue as last time this happened.

Code: Select all

Feb 20 18:56:17	nas	smbd[3243]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/stuff/public, failed - NT_STATUS_ACCESS_DENIED.
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850650, 0] ../source3/modules/vfs_default.c:1375(vfswrap_fsctl)
Feb 20 18:56:17	nas	smbd[3243]: access denied on listing snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850639, 0] ../source3/modules/vfs_shadow_copy2.c:2063(shadow_copy2_get_shadow_copy_data)
Feb 20 18:56:17	nas	smbd[3243]: user does not have list permission on snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850611, 0] ../source3/modules/vfs_shadow_copy2.c:1847(check_access_snapdir)

Last time I remember using it was NAS4Free-x64-embedded-11.1.0.4.5019 so might have been either this version or last version that broke it.

[raulfg3]

Windows Previous versions broke again, same permission issue as last time this happened.

Code: Select all

Feb 20 18:56:17	nas	smbd[3243]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/stuff/public, failed - NT_STATUS_ACCESS_DENIED.
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850650, 0] ../source3/modules/vfs_default.c:1375(vfswrap_fsctl)
Feb 20 18:56:17	nas	smbd[3243]: access denied on listing snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850639, 0] ../source3/modules/vfs_shadow_copy2.c:2063(shadow_copy2_get_shadow_copy_data)
Feb 20 18:56:17	nas	smbd[3243]: user does not have list permission on snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850611, 0] ../source3/modules/vfs_shadow_copy2.c:1847(check_access_snapdir)

Last time I remember using it was NAS4Free-x64-embedded-11.1.0.4.5019 so might have been either this version or last version that broke it.

Use SMB instead NTLM

[Onichan]

Windows Previous versions broke again, same permission issue as last time this happened.

Code: Select all

Feb 20 18:56:17	nas	smbd[3243]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/stuff/public, failed - NT_STATUS_ACCESS_DENIED.
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850650, 0] ../source3/modules/vfs_default.c:1375(vfswrap_fsctl)
Feb 20 18:56:17	nas	smbd[3243]: access denied on listing snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850639, 0] ../source3/modules/vfs_shadow_copy2.c:2063(shadow_copy2_get_shadow_copy_data)
Feb 20 18:56:17	nas	smbd[3243]: user does not have list permission on snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850611, 0] ../source3/modules/vfs_shadow_copy2.c:1847(check_access_snapdir)

Last time I remember using it was NAS4Free-x64-embedded-11.1.0.4.5019 so might have been either this version or last version that broke it.

Use SMB instead NTLM

Not sure what you mean? Only NTLM I know of is the Auth protocol, If I do ntlm auth = disabled then it breaks my shares. Nothing coming to mind about SMB auth.

[raulfg3]

https://www.nas4free.org/forums/viewtop ... 21&t=13436

[Onichan]

https://www.nas4free.org/forums/viewtop ... 21&t=13436

Are you talking about SMBv1 vs SMBv2? If so I already disabled SMBv1 on mine last year as well for security reasons. All four options Server Max. Protocol, Server Min. Protocol, Client Max. Protocol and Client Min. Protocol are set to SMB2.

[JoseMR]

Windows Previous versions broke again, same permission issue as last time this happened.

Code: Select all

Feb 20 18:56:17	nas	smbd[3243]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/stuff/public, failed - NT_STATUS_ACCESS_DENIED.
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850650, 0] ../source3/modules/vfs_default.c:1375(vfswrap_fsctl)
Feb 20 18:56:17	nas	smbd[3243]: access denied on listing snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850639, 0] ../source3/modules/vfs_shadow_copy2.c:2063(shadow_copy2_get_shadow_copy_data)
Feb 20 18:56:17	nas	smbd[3243]: user does not have list permission on snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850611, 0] ../source3/modules/vfs_shadow_copy2.c:1847(check_access_snapdir)

Last time I remember using it was NAS4Free-x64-embedded-11.1.0.4.5019 so might have been either this version or last version that broke it.

Hello, a workaround for this issue(if ZFS ACL not required) is to disable the "ZFS ACL" support for each share under "Services > CIFS/SMB > Share > Edit"
Regards

[Onichan]

Windows Previous versions broke again, same permission issue as last time this happened.

Code: Select all

Feb 20 18:56:17	nas	smbd[3243]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/stuff/public, failed - NT_STATUS_ACCESS_DENIED.
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850650, 0] ../source3/modules/vfs_default.c:1375(vfswrap_fsctl)
Feb 20 18:56:17	nas	smbd[3243]: access denied on listing snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850639, 0] ../source3/modules/vfs_shadow_copy2.c:2063(shadow_copy2_get_shadow_copy_data)
Feb 20 18:56:17	nas	smbd[3243]: user does not have list permission on snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850611, 0] ../source3/modules/vfs_shadow_copy2.c:1847(check_access_snapdir)

Last time I remember using it was NAS4Free-x64-embedded-11.1.0.4.5019 so might have been either this version or last version that broke it.

Hello, a workaround for this issue(if ZFS ACL not required) is to disable the "ZFS ACL" support for each share under "Services > CIFS/SMB > Share > Edit"
Regards

That fixed it, thank you. The only reason I had ZFS ACL's enabled was a while back the logs were getting spammed if they weren't enabled.

[tonyd]

Windows Previous versions broke again, same permission issue as last time this happened.

Code: Select all

Feb 20 18:56:17	nas	smbd[3243]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/stuff/public, failed - NT_STATUS_ACCESS_DENIED.
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850650, 0] ../source3/modules/vfs_default.c:1375(vfswrap_fsctl)
Feb 20 18:56:17	nas	smbd[3243]: access denied on listing snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850639, 0] ../source3/modules/vfs_shadow_copy2.c:2063(shadow_copy2_get_shadow_copy_data)
Feb 20 18:56:17	nas	smbd[3243]: user does not have list permission on snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850611, 0] ../source3/modules/vfs_shadow_copy2.c:1847(check_access_snapdir)

Last time I remember using it was NAS4Free-x64-embedded-11.1.0.4.5019 so might have been either this version or last version that broke it.

Hello, a workaround for this issue(if ZFS ACL not required) is to disable the "ZFS ACL" support for each share under "Services > CIFS/SMB > Share > Edit"
Regards

That fixed it, thank you. The only reason I had ZFS ACL's enabled was a while back the logs were getting spammed if they weren't enabled.

I had the same problem with this build. I haven't touched my CIFS/SMB settings in a long time. This workaround also worked for me (needed to restart the CIFS/SMB service after updating the shares).

Before applying the workaround I was getting basically the same thing in the logs:

Code: Select all

Feb 24 22:52:15	fs	smbd[10234]: [2018/02/24 22:52:15.438193, 0] ../source3/modules/vfs_shadow_copy2.c:1847(check_access_snapdir)
Feb 24 22:52:15	fs	smbd[10234]: user does not have list permission on snapdir /mnt/pool1/dsets/public/.zfs/snapshot
Feb 24 22:52:15	fs	smbd[10234]: [2018/02/24 22:52:15.438225, 0] ../source3/modules/vfs_shadow_copy2.c:2063(shadow_copy2_get_shadow_copy_data)
Feb 24 22:52:15	fs	smbd[10234]: access denied on listing snapdir /mnt/pool1/dsets/public/.zfs/snapshot
Feb 24 22:52:15	fs	smbd[10234]: [2018/02/24 22:52:15.438239, 0] ../source3/modules/vfs_default.c:1375(vfswrap_fsctl)
Feb 24 22:52:15	fs	smbd[10234]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/pool1/dsets/public, failed - NT_STATUS_ACCESS_DENIED.

[Viper780]

I've tried to download the latest Files

The NAS4Free Team is pleased to announce the release of version 11.1.0.4.5127 - Atomics

Download build 11.1.0.4.5127

BUILD 11.1.0.4.5127

But on SF I'm getting an 500 Error that the "https://sourceforge.net/projects/nas4free/files/" is missing.
Is there any mirror? Or can I expect a new version soon?

best regards
Daniel

[ms49434]

SourceForge recently migrated to a new datacenter and new hardware. There are issues here and there - SF.net ops do their best to stabilize the platform.
You can get the latest SF.net operations updates from here: https://twitter.com/sfnet_ops

[danzi]

11.1.0.4 - Atomics (revision 5127)


Slight formatting discrepancy between the two pages below:

Disks - ZFS - Configuration - Current

v.s.

Disks - ZFS - Configuration - Detected

[raulfg3]

can you please post a screen capture or someting to check?

[Tommy.Z]

WOL on my N36L is now working!
Thanks

[doktornotor]

Windows Previous versions broke again, same permission issue as last time this happened.

Code: Select all

Feb 20 18:56:17	nas	smbd[3243]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/stuff/public, failed - NT_STATUS_ACCESS_DENIED.
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850650, 0] ../source3/modules/vfs_default.c:1375(vfswrap_fsctl)
Feb 20 18:56:17	nas	smbd[3243]: access denied on listing snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850639, 0] ../source3/modules/vfs_shadow_copy2.c:2063(shadow_copy2_get_shadow_copy_data)
Feb 20 18:56:17	nas	smbd[3243]: user does not have list permission on snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850611, 0] ../source3/modules/vfs_shadow_copy2.c:1847(check_access_snapdir)

Last time I remember using it was NAS4Free-x64-embedded-11.1.0.4.5019 so might have been either this version or last version that broke it.

Use SMB instead NTLM

Not really sure what you mean here. We have SMB1 completely disabled across the entire network (not installed on W2016 servers, and disabled via GPO on workstations.) Yet, definitely seeing https://bugzilla.samba.org/show_bug.cgi?id=13175

[raulfg3]

Windows Previous versions broke again, same permission issue as last time this happened.

Code: Select all

Feb 20 18:56:17	nas	smbd[3243]: FSCTL_GET_SHADOW_COPY_DATA: connectpath /mnt/stuff/public, failed - NT_STATUS_ACCESS_DENIED.
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850650, 0] ../source3/modules/vfs_default.c:1375(vfswrap_fsctl)
Feb 20 18:56:17	nas	smbd[3243]: access denied on listing snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850639, 0] ../source3/modules/vfs_shadow_copy2.c:2063(shadow_copy2_get_shadow_copy_data)
Feb 20 18:56:17	nas	smbd[3243]: user does not have list permission on snapdir /mnt/stuff/public/./.zfs/snapshot
Feb 20 18:56:17	nas	smbd[3243]: [2018/02/20 18:56:17.850611, 0] ../source3/modules/vfs_shadow_copy2.c:1847(check_access_snapdir)

Last time I remember using it was NAS4Free-x64-embedded-11.1.0.4.5019 so might have been either this version or last version that broke it.

Use SMB instead NTLM

Not really sure what you mean here. We have SMB1 completely disabled across the entire network (not installed on W2016 servers, and disabled via GPO on workstations.) Yet, definitely seeing https://bugzilla.samba.org/show_bug.cgi?id=13175

Yes, sorry. the problem is ACL related and not NT1(SMB) related.