NAS

Add me to the list of people. I am very surprised about this limitation and would like to be pointed at more info. Are we treating this as a bug to fix (because IMHO it is a serious one)

Thanks everyone, I have done so. Anyone know what the back story to this is? 2017.07.09c ..Add: Warning in the format and partition dialog that a UD partitioned disk cannot be added to the array.

That is certainly not the case here. I have never seen anything other than "Stop". For example this is what I see this now:

Polite bump

Apologies if this is covered but this thread is too long to review. When you use preclear, once complete you are left with two confusingly contradictory options: "Preclear Finished Successfully!" and "Stop preclear". Should the "Stop preclear" Red X still be available when preclear is no longer running? Or is the nature of what "Stop preclear" means different after it completes and the wording is just confusing in that context.?

There is DMCA in place. See the readme.

This is a really interesting bug. I realise you now have a fix but I suspect like me you want to know wtf is going on. Step 1 if it was me is I would determine if it line saturation or line shaping. Debugging the former is much easier than the later but my gut is telling me is either your fw, cpe or upstream providers is shaping the link based on some packet matching seen from deluge. pfsense still has bandwidth graphs doesnt it?. If so you should easily be able to spot a bw spike given how large you internet connection is.

Just to clarify, is your link being saturated or is your link speed dropping?

I dont see why not. Other that it is not a typical use case you should easily be able to lock this down by IP address and port. Special warning though, if you use docker there are extra iptables issues you will need to address.

I would like to move beyond talking about Wannacary as it is too narrow a focus. Happy to fork the thread although all the right people are monitoring this one so if we can stay it would be better. There are several protocol level problems with SMBv1 that cant and wont ever be fixed and it has been deprecated as a recommended protocol for quite some time now by all the relevant players. A generic non exploit related example of SMBv1 failure is that there are known issues where legacy devices/OS will "fail low" and handshake below SMBv2 even when they are far more capable just because SMBv1 exists on the remote server. I do not deny that universally disabling SMBv1 would break equipment and it is why i specifically did not suggest this but it is clear that there is a subsection of the userbase that do not need it, some that dont need it but unknowingly still use it and yet others who have no idea and will need some help with the topic as a whole. Saying all that I can see that more compatibility is a simpler stance and has many benefits in itself but I definitely dont believe it is the most secure stance we could take. Ultimately the decision is yours if we want to take a proactive approach to security vs ultimate compatibility.

Will do once we debate it out here first.... unless I nailed it on first try? Also http://www.theregister.co.uk/2017/06/22/latest_windows_10_build_kills_exploited_smb1/

I would like to suggest that we make the disabling of what we are calling SMBv1 via the GUI as a checkbox. This way we can inform the users of the downsides, why it should happen and the rarer cases where it shouldnt. We do need to debate what the default should be. At some point SMBv2+ should be the default but I do not think that day has come yet. Regardless this should be a point and click skill-free exercise for users and not a lengthy forum read should they happen upon it.

FWIW the default inclusion of pre SMBv2 "anything" is going to fail nessus and pci, that is a given.

If you are testing with Kodi the specific version you are using on which platform is important as for instance there is a lot of work happening right now in LibreELEC land for this and as usual none at all in OpenELEC. As I understand it almost every Kodi instance out there in the wild is currently limited to SMBv1 using native app shares i.e. sources.xml. This is a Kodi limit not an OS one. Milhouse LibreELEC builds however as usual are ahead of the curve.

The OP is disable NTLM1.2 in light of the WannaCry exploit and not as a fix the WannaCry exploit. Sensible advice but it is a much bigger topic and needs more resources to tackle.

Have you confirmed this works as you expect it to? For instance there is a lot of information out there that ` client min protocol = SMB2 ` breaks peoples client and does not do what it appears to do on the face of it and may break the upper level some client negotiate to. Also it is not clear to me that since the extra config is simply an insert statement within the RO smb.conf adding statement like ` ntlm auth = no` is essentially like having yes and no set in the same config file. I have no idea if this works officially, coincidentally or not at all. I think given the hidden complexity of this topic and the seriousness of it we need the big guns. I will ping them now.

No issues with upgrade here.

So I looked into this some more. The whole NetBIOS/SMB 139/445 thing is way more complicated than it seems on first look but most of it would be out of scope for this thread. The important bit is that the port 445 recommendations are just badly worded as we expected. What it essentially mean is "dont trust 445 anymore on a network you dont trust". This is not new advice and no one should have been doing this for as long as I can remember. Thanks for the links.

I am not sure I follow that one. Disabling 445 would kill all of NetBIOS SMB so I can only assume they are talking about between zones or the interent... and if you have that open you have bigger problems to deal with Or am i reading it wrong? Edit: this actually doesn't work the way I thought it did. More reading required

This obviously is a big topic and will have many foreseen issues (old kit no longer working with modern SMB2+) and unforeseen ones (e.g. Kodi may only support NT1). It needs done though and has for a while. Curious where you are seeing the port 445 recommendation, can you link me?

You guys have me convinced now. The Blizard and FreeNAS posts sealed the deal on the argument for me.

Checkout docker-compose.

Thats great thanks. I read it wrongly as a bug fix which peaked my interest. This feature upgrade is good too obviously. Cheers

Intersting update. The the exact same setup as before with the exception of moving to 6.3.3 and adding 16GB more RAM some of the stats have increased btrfs_inode 18189 19950 1072 30 8 : tunables 0 0 0 : slabdata 665 665 0 mqueue_inode_cache 72 72 896 18 4 : tunables 0 0 0 : slabdata 4 4 0 v9fs_inode_cache 0 0 648 25 4 : tunables 0 0 0 : slabdata 0 0 0 xfs_inode 1481005 1481272 960 17 4 : tunables 0 0 0 : slabdata 88842 88842 0 udf_inode_cache 0 0 728 22 4 : tunables 0 0 0 : slabdata 0 0 0 fuse_inode 1769711 1769843 768 21 4 : tunables 0 0 0 : slabdata 85799 85799 0 cifs_inode_cache 0 0 736 22 4 : tunables 0 0 0 : slabdata 0 0 0 nfs_inode_cache 0 0 936 17 4 : tunables 0 0 0 : slabdata 0 0 0 isofs_inode_cache 0 0 624 26 4 : tunables 0 0 0 : slabdata 0 0 0 fat_inode_cache 644 644 712 23 4 : tunables 0 0 0 : slabdata 28 28 0 ext4_inode_cache 0 0 1024 16 4 : tunables 0 0 0 : slabdata 0 0 0 reiser_inode_cache 402622 402622 736 22 4 : tunables 0 0 0 : slabdata 18301 18301 0 rpc_inode_cache 0 0 640 25 4 : tunables 0 0 0 : slabdata 0 0 0 inotify_inode_mark 184 184 88 46 1 : tunables 0 0 0 : slabdata 4 4 0 sock_inode_cache 1675 1675 640 25 4 : tunables 0 0 0 : slabdata 67 67 0 proc_inode_cache 53632 53775 632 25 4 : tunables 0 0 0 : slabdata 2151 2151 0 shmem_inode_cache 16848 16848 680 24 4 : tunables 0 0 0 : slabdata 702 702 0 inode_cache 7840 7840 576 28 4 : tunables 0 0 0 : slabdata 280 280 0 I can only assume i have cached some inodes that are excluded from cache_dirs. Will see how the numbers change over time