ZFS: Samba or iSCSI

I would like to store all my data on my FreeBSD server that uses (only) ZFS. I'll be accessing the data from a Windows machine It looks like I have two options for accessing the data on the server from a Windows machine:

1) Create a ZVOL and setup iSCSI. Then use the iSCSI initiator in Windows to connect to the ZVOL and then format the partition with NTFS and just access the data via a local drive letter in Windows. The downside to this is that my data still sits on an NTFS partition.

2) Put all my data directly on a ZFS drive in my server and access the data via a mapped drive from Windows using Samba on the server.

I like the idea of accessing my data via a drive letter in Windows but will ZFS checksumming and data integrity still work for me since my data will be on an NTFS partition (that sits on top of ZFS)?

Or is it safer/better to go the Samba route and just use a mapped drive?

I'm running FreeBSD 10-STABLE on the server and Windows 8.1 on the desktop.
 
SAMBA is certainly simpler to set up and at least in my experience a very robust and trouble free solution. YMMV.
 
I'd use Samba, as @kpa noted, it's easier to set up and you still benefit from all the ZFS features. Windows applications won't know (or care) if it's a local drive or a mapped drive.
 
Last edited by a moderator:
Do you want to share the data between FreeBSD and Windows? By "share the data" I mean: be able to access Windows files? For example, you might be running a glimpse server on your FreeBSD machine (to search files, like a miniature google in your server); would it be desirable for you to access Windows files in the same way?

If yes, you have to go with something like Samba.

The other advantage of Samba is that you share the disk space: You don't have to reserve a certain number of gigabytes to the Windows disk, but instead you can freely mix Windows and Unix files in the same file system.

Setting up Samba is not completely trivial; in particular handling user id mapping and passwords cost me a lot of time the last time I had to set it up. Not rocket science, but tedious (at least to me).
 
In your setup I recommend what was already said - samba. Though you didn't describe the environment, I've a feeling it is home-like setup. It's definitely easier to scale if you want to share the data among other clients too (when the opportunity arrives).

I do use iSCSI (though SUN shines :) over my iSCSI server), but it's better for a scenario where you benefit from accessing the entire LUN (e.g. clusters).

Couple years ago I used iSCSI LUN presented to my Windows XP notebook. I was able to encrypt the traffic and hence listen to mp3s which were not allowed on my company notebook. :)
 
Yes, this is a home network. I will *only* have one Windows 8.1 client accessing the files on the FreeBSD. I prefer the idea of iSCSI since Windows sees the data on the server as a local drive letter but then I have to use NTFS which in turn sits on top of ZFS. Does checksumming in ZFS help protect my data here?

Using Samba would mean all my data is sitting directly on top of ZFS which would be ideal.

One thing that concerns me about both options is: Security. How safe is the data travelling over the wire as I access it via iSCSI or Samba?

I know Samba has SMB3 which supports signing and encryption of the data so I assume this stops someone sniffing your login credentials when logging onto the Samba server AND prevents someone seeing what data you are accessing?

Is the iSCSI traffic between client and server secure/encrypted?
 
xy16644 said:
I prefer the idea of iSCSI since Windows sees the data on the server as a local drive letter
If the goal is to have the letter 'thingy', you still have an option to map the remote share as a drive (to map a share).

xy16644 said:
Is the iSCSI traffic between client and server secure/encrypted?
Not by default. At home I would not pay much attention to it. But you can authenticate initiators with CHAP, you can use IPsec to encrypt the traffic. Or you can encrypt the LUN on top (e.g. truecrypt, geli, ..) and then push data to it.

I've never seen encrypted samba share (not that it's not possible /IPsec?/). Usually clients are accessing shares using some sort of VPN. Or SSH tunnel. Encryption is hence handled by that.
 
xy16644 said:
Yes, this is a home network. I will *only* have one Windows 8.1 client accessing the files on the FreeBSD. I prefer the idea of iSCSI since Windows sees the data on the server as a local drive letter but then I have to use NTFS which in turn sits on top of ZFS. Does checksumming in ZFS help protect my data here?
ZFS uses checksumming on all data blocks in the pool.
It doesn't matter if these blocks are used by a ZFS filesystem or by a ZVOL.
Any checksum errors will be automatically corrected, provided your pool has enough redundancy, like using a mirror, zraid or the copies > 1 option.
 
When I talk about encryption, I mean the actual data travelling across the wire. The data is already stored encrypted on a geli ZFS pool but what I want to know is, will using SMB3 fully encrypt the data between my machine (the machine accessing the data) and the server (where the data will be stored).

The little I have read seems to indicate yes if you force encryption in Samba with SMB3 (or 3.02).
 
Are you expecting someone to break into your house and install something to eavesdrop on the link between your server and your desktop?
If they remotely hack your server or desktop due to a virus or remote vulnerability (the slightly more likely option) then they'll just access the data directly and your encryption (either on the network traffic or block storage) will be irrelevant.

Edit: Reading a bit on smb.conf (probably the same bit as you), it does look like you can force encryption for all traffic with smb encrypt = mandatory. The docs say it isn't supported by Windows but they could just be out of date. Windows 8 is supposed to support it. You could always set the above encryption option and see what happens. I still see it as a waste of time and resources though if you're just accessing data across your local lan.
 
usdmatt said:
Are you expecting someone to break into your house and install something to eavesdrop on the link between your server and your desktop?
If they remotely hack your server or desktop due to a virus or remote vulnerability (the slightly more likely option) then they'll just access the data directly and your encryption (either on the network traffic or block storage) will be irrelevant.

Edit: Reading a bit on smb.conf (probably the same bit as you), it does look like you can force encryption for all traffic with smb encrypt = mandatory. The docs say it isn't supported by Windows but they could just be out of date. Windows 8 is supposed to support it. You could always set the above encryption option and see what happens. I still see it as a waste of time and resources though if you're just accessing data across your local lan.

I'm big on security and take it seriously. If encryptions an option, why not use it? To me, it just makes sense. And, I like the challenge.

I don't have it handy right now but I did bookmark it at work where they were discussing some registry/local group policy changes you can make in Windows to enforce signing/encrpyting SMB3 traffic. Theres also some talk of it at Samba. I'm keen to try this out and see what happens!
 
Hi @xy16644!

If it´s just you doing normal "unstructured" file sharing then SAMBA is certainly the easiest choice.

Just wanted to chip in- contrary to other statements here- that some MS applications actually do care whether it´s a "disk" or a "share" and refuse to work on shares for different reasons. One of them being that share path gets "too long" to access all of the files ("D:\" vs. "\\somereallylongandsillyhostname.foo.bar\equallylongandsillysharename\"). That´s a MS decision based on the fact that Windows Explorer is(or has been anyway) limited in the number of characters it can handle. Ridiculous, but that´s their call. Another reason is being very strict in how access is set up on the volume and needs direct control to manipulate ACL's. For these reasons it is more common to serve out iSCSI to Windows servers.

But that is regarding to running those applications as services in a more structured manner, so doesn´t really apply in your case.

/Sebulon
 
Last edited by a moderator:
After giving this much thought and research I came to the conclusion that neither iSCSI nor Samba is the correct choice for me. Why? Well with iSCSI I still have to use the NTFS filesystem (which I don't want) and Samba isn't secure enough (although you can enable signing/encryption for SMB). I wanted my data to sit directly on top of ZFS for maximum protection (and not to use any other filesystem at all).

This weekend I found, what I think, is the solution to my problem :) Why not use my existing SSH/SFTP and then (somehow) map a drive from my Windows machine to a directory on the server? That way everything is encrypted and secure AND I can make use of my key based authentication! And my data will sit on top of ZFS! Perfect.

I am currently testing this with a Windows program called "SFTP Net drive Pro" and its working really well. You can either have the drive appear in Windows as a mapped drive or (as I have chosen) have the drive appear as a local drive. It works so well that I may even purchase the Pro version of this software (which is required for pageant support). The nice thing about this approach is that I don't need to configure anything new on my server...I just make use of SSH/SFTP which is already installed and configured.

For those interested there is a free version of SFTP Netdrive but you can't use pageant authentication and there are many other restrictions. The downside of the Pro edition is the price: £52 (ouch). Details are here:

https://www.eldos.com/sftp-net-drive/

I did look at other free programs that allow you to map a drive from Windows to an SFTP/SSH connection but none were great and most (if not all) didn't support key based authentication.

Oh, the performance over SSH/SFTP is slower using all that encryption but I don't mind at all as its only a backup copy of my data. When I update this data on the server over SSH/SFTP its not usually much so I don't mind the speed being much slower than an unencrypted connection.
 
Another point to think of:
If you use Samba you can use ZFS snapshots and provide file level recovery.
Or if you decide to go with iSCSI you can only roll back the whole LUN/ZVOL snapshot if you mess up some files and need to recover them.

So I vote for Samba because of more flexibility.
 
gqgunhed said:
Another point to think of:
If you use Samba you can use ZFS snapshots and provide file level recovery.
Or if you decide to go with iSCSI you can only roll back the whole LUN/ZVOL snapshot if you mess up some files and need to recover them.

So I vote for Samba because of more flexibility.

I vote for neither :e

If you map a Windows drive via SFTP/SSH using the program I mentioned, then the data sits directly on top of ZFS. Therefore all the usual applies to snapshots.

The biggest benefit of my approach is that you are using the tried and tested security/authentication/encryption of OpenSSH rather than using Samba (and having to make sure that SMB packets are encrypted/signed).

But good point re having to rollback an ENTIRE ZVOL when using a snapshot. When I need to restore a file from a ZFS snapshot (for non-ZVOL data) I like to just copy the needed file out of the .zfs directory rather than rolling back an entire snapshot.
 
I think it should be possible to clone a snapshot and then export that separately via iSCSI, so you could mount that as a separate drive in Windows and pull just the files you need. Still a lot more hassle than Samba though, especially if you've put the few lines into smb.conf that allow you to browse ZFS snapshots using the 'Previous Versions' browser directly from Windows.
 
Back
Top