SMB vs NFS

I read recently that Microsoft has made its Services For Unix (SFU) free.
Since I use a Linux server, I thought it may be worth switching my file
sharing from Samba to NFS.

Does anybody have any comments on this? I understand setting up the Windows
side of things will be more difficult than using SMB, but the Linux side
will be a bit easier, won't it?

My Windows machine also exports some directories so that my Linux server can
access them. I gather this will become easier by switching solely to an NFS
solution.

cheers,

C3

My two cents:

Bad idea.

From what I have seen of SFU, the performance is horrid, and the
only work around is to enable write caching at the server. This
speeds things up, but also violates the NFS V3 specification by
making COMMITS async, and not guaranteed to be completed
to stable storage. If you don't mind losing your data, it might work
for you :-(
Systems that I have measured with NFS V3 semantics being
properly handled indicate that on identical hardware, SFU's NFS
is roughly 8 times slower than the same hardware running a
Linux distro.
Sometimes there are things in the universe that do not exist, and
that too is an indication of something. Have you ever noticed that
the industry standard benchmark for NFS, SPEC SFS, has NO
results for systems running SFU ? There is probably a very good
reason for this :-)

Have fun,
Mangled & Munged


"C3" <gned@telsMONOPOLYtra.com> wrote in message
news:401b7e93$0$28866$afc38c87@news.optusnet.com.a u...
> I read recently that Microsoft has made its Services For Unix (SFU) free.
> Since I use a Linux server, I thought it may be worth switching my file
> sharing from Samba to NFS.
>
> Does anybody have any comments on this? I understand setting up the
Windows
> side of things will be more difficult than using SMB, but the Linux side
> will be a bit easier, won't it?
>
> My Windows machine also exports some directories so that my Linux server
can
> access them. I gather this will become easier by switching solely to an
NFS
> solution.
>
> cheers,
>
> C3
>
>

"C3" <gned@telsMONOPOLYtra.com> wrote in message news:<401b7e93$0$28866$afc38c87@news.optusnet.com. au>...
> I read recently that Microsoft has made its Services For Unix (SFU) free.

For the past year or so, I believe.

> Since I use a Linux server, I thought it may be worth switching my file
> sharing from Samba to NFS.

If the only sharing is to Win boxes, you may want to stay with Samba
for now. It continues to make improvements in reliablilty and
services offered. It's "native" to Win and does not require manual
setup at each Win host as I suspect you'll face with NFS. With Samba,
you "just" have your server to maintain.

> Does anybody have any comments on this? I understand setting up the Windows
> side of things will be more difficult than using SMB, but the Linux side
> will be a bit easier, won't it?

See comments below, but I suspect that this will not be the case.
Setting up the Linux box will go reasonably well, but getting it to
play nice with the Win boxes could be a can of worms depending how you
intend to use NFS.

> My Windows machine also exports some directories so that my Linux server can
> access them. I gather this will become easier by switching solely to an NFS
> solution.

Do see the comments below!

> cheers,
>
> C3

Last Spring I attempted to help someone trying to get NFS working
between Win2000 (server) and (RH?)Linux boxes (client). He finally
gave up the initial attempt. The issues were:

--Win was running NFS from 3rd party that MS used before writing their
own stuff (I don't think there are major differences, but you know how
MS treats their "partners"...)
-- establising the connections went OK
-- major pain for him was the differences in how Win and Linux were
treating UTF8 filenames
-- this was a major stumbling block as some directories/files were
using a Swedish locale and they became inaccessible in Linux
-- these kinds of problems may/likely do vary with Linux distro as the
libraries containing the translation routines vary as do the apps
using various libraries
-- MS seems determined to use its versions of Unicode formats and
Linux has not (yet?) gotten their UTF8 code working properly in all
places
-- and there are questions re: properly complete fonts for some of the
ANSI chars in Linux
-- this suggests to me that you will likely run into some problems, so
check things out on Google, get the latest updates re: UTF8 for Linux,
and snoop around MS for any info/gotchas
-- depending on what you expect to _gain_ by using NFS, note that
Linux implementation is incomplete compared to Solaris (the guy above
also had a Sun box that worked reasonably OK with W2K), especially re:
automounting and autofs
-- suspect that Win implementation of NFS (client and server) has some
gotchas

To be best prepared, I would suggest any trials be run from
non-production/non-critical boxes as much as possible.

Hopefully, someone with more direct and more recent experience can
chime in.

hth,
prg
email above disabled

Interesting... The setup I have at the moment involves one Win2k machine and
my Linux server which is directly connected to the internet. My win2k
machine shares some directories via SMB, and my Linux machine also shares
some directories via SMB.

I'd like to be able to mount drives from either my Linux or Windows machine
over the internet. Is it possible to remotely mount Samba shares through
SSH? Similarly, is this possible from a Windows client (also via SSH)?


cheers,

C3

So anyway, it was like, 08:40 CET Feb 02 2004, you know? Oh, and, yeah,
C3 was all like, "Dude,

> I'd like to be able to mount drives from either my Linux or Windows
> machine over the internet. Is it possible to remotely mount Samba
> shares through SSH? Similarly, is this possible from a Windows
> client (also via SSH)?

Call me old-fashioned, but.. mounting smb (or any) shares over the
internet? You do have a /really/ tight firewall setup on that box to
only allow the machines you expect to reach you, right?

Not to mention that you'll be wasting a whole lot of precious
bandwidth to accommodate a protocol which is not exactly.. slim.

What is the purpose of this sharing? You might want to consider using
something like sftp (included with most ssh clients) instead to fetch
files in a more secure and less distaster-inviting manner.

--
Time flies like an arrow, fruit flies like a banana. Perth ---> *
10:12:54 up 8 days, 17:48, 3 users, load average: 3.27, 3.55, 3.21
$ cat /dev/bollocks Registered Linux user #261729
seize customized portals

> Call me old-fashioned, but.. mounting smb (or any) shares over the
> internet? You do have a /really/ tight firewall setup on that box to
> only allow the machines you expect to reach you, right?

Yes. SSH access is restricted to a few IP subnets where I know I'll be, and
only at the times I'll be there. I'm also about to start trialing an even
more secure firewall. I've come up with a trick - and I don't know whether
it will work - that requires you to probe the ports of the machine in a
certain order within a certain timeframe to get access (but this is
offtopic).

> Not to mention that you'll be wasting a whole lot of precious
> bandwidth to accommodate a protocol which is not exactly.. slim.

I know that SMB is not exactly the most efficient protocol, but I'm only
doing this for convenience. I will not be transferring large files. More
like running programs remotely that write to config/log files in one place.

> What is the purpose of this sharing? You might want to consider using
> something like sftp (included with most ssh clients) instead to fetch
> files in a more secure and less distaster-inviting manner.

Convenience. I already use scp to transfer files that don't need to be
updated often. What is so disaster-inviting about running SMB over SSH so I
can have live access to my config files? This is what I'll be doing.


cheers,

C3

So anyway, it was like, 11:51 CET Feb 02 2004, you know? Oh, and, yeah,
C3 was all like, "Dude,

>> Call me old-fashioned, but.. mounting smb (or any) shares over the
>> internet? You do have a /really/ tight firewall setup on that box
>> to only allow the machines you expect to reach you, right?
>
> Yes. SSH access is restricted to a few IP subnets where I know I'll
> be, and only at the times I'll be there. I'm also about to start
> trialing an even more secure firewall.

(I'm assuming you mean "SMB".)

> I've come up with a trick - and I don't know whether it will
> work - that requires you to probe the ports of the machine in a
> certain order within a certain timeframe to get access (but this is
> offtopic).

You're not the first person to come up with the idea (well, you might
be, if you called it "port knocking").

<http://www.linuxjournal.com/article.php?sid=6811>

It's an interesting concept, but personally I feel it's alittle over
the top for a non-professional setting.

>> Not to mention that you'll be wasting a whole lot of precious
>> bandwidth to accommodate a protocol which is not exactly.. slim.
>
> I know that SMB is not exactly the most efficient protocol, but I'm
> only doing this for convenience. I will not be transferring large
> files. More like running programs remotely that write to config/log
> files in one place.

Convenience is one of the biggest culprits when it comes to creating
security problems, imho.

>> What is the purpose of this sharing? You might want to consider
>> using something like sftp (included with most ssh clients) instead
>> to fetch files in a more secure and less distaster-inviting manner.
>
> Convenience. I already use scp to transfer files that don't need to
> be updated often. What is so disaster-inviting about running SMB
> over SSH so I can have live access to my config files? This is what
> I'll be doing.

As for smb over ssh, I dunno, I don't even know if it can be done (it
probably can). As for actually mounting file systems (read-write, no
less!) over the internet, it's just so.. wrong. Especially nfs, I
guess smb would be slightly less stupid security-wise since it's at
least partially encrypted.

What config files (or log files, for that matter) is it that you need
to be able to update remotely in this manner? I'm quite curious,
since I can't figure out a good enough reason to require this sort of
procedure. :)

--
Time flies like an arrow, fruit flies like a banana. Perth ---> *
12:41:53 up 8 days, 20:17, 3 users, load average: 2.10, 2.14, 2.10
$ cat /dev/bollocks Registered Linux user #261729
engage distributed networks

Johan Lindquist <spam@smilfinken.net> wrote in message news:<85q1f1-j3c.ln1@news.smilfinken.net>...
> So anyway, it was like, 11:51 CET Feb 02 2004, you know? Oh, and, yeah,
> C3 was all like, "Dude,
>
> >> Call me old-fashioned, but.. mounting smb (or any) shares over the
> >> internet? You do have a /really/ tight firewall setup on that box
> >> to only allow the machines you expect to reach you, right?
> >
> > Yes. SSH access is restricted to a few IP subnets where I know I'll
> > be, and only at the times I'll be there. I'm also about to start
> > trialing an even more secure firewall.
>
> (I'm assuming you mean "SMB".)
>
> > I've come up with a trick - and I don't know whether it will
> > work - that requires you to probe the ports of the machine in a

security tricks that are not known to work simply don't

> > certain order within a certain timeframe to get access (but this is
> > offtopic).
>
> You're not the first person to come up with the idea (well, you might
> be, if you called it "port knocking").
>
> <http://www.linuxjournal.com/article.php?sid=6811>
>
> It's an interesting concept, but personally I feel it's alittle over
> the top for a non-professional setting.
>
> >> Not to mention that you'll be wasting a whole lot of precious
> >> bandwidth to accommodate a protocol which is not exactly.. slim.
> >
> > I know that SMB is not exactly the most efficient protocol, but I'm
> > only doing this for convenience. I will not be transferring large
> > files. More like running programs remotely that write to config/log
> > files in one place.
>
> Convenience is one of the biggest culprits when it comes to creating
> security problems, imho.
>
> >> What is the purpose of this sharing? You might want to consider
> >> using something like sftp (included with most ssh clients) instead
> >> to fetch files in a more secure and less distaster-inviting manner.
> >
> > Convenience. I already use scp to transfer files that don't need to
> > be updated often. What is so disaster-inviting about running SMB
> > over SSH so I can have live access to my config files? This is what
> > I'll be doing.
>
> As for smb over ssh, I dunno, I don't even know if it can be done (it
> probably can). As for actually mounting file systems (read-write, no
> less!) over the internet, it's just so.. wrong. Especially nfs, I
> guess smb would be slightly less stupid security-wise since it's at
> least partially encrypted.
>
> What config files (or log files, for that matter) is it that you need
> to be able to update remotely in this manner? I'm quite curious,
> since I can't figure out a good enough reason to require this sort of
> procedure. :)

Afraid I must concur with Johan's scepticism re: both the "dangers of
convenience" and the need to mount partitions and/or shares across the
internet. When it comes to outside access to a system, if you don't
_know_ it is safe, it is _not_ safe.

The port knocking depends largely on security-thru-obscurity. Anyone
who does get in will quickly clean up the logs to hide they were ever
there. The fact that you will be connecting from only a few subnets
is also of dubious help -- it only reduces the range of valid IP's
accepted. Besides, without an acknowledgement mechanism, there is no
way know to be certain that the connection attempts will arrive in the
order that you sent them -- this whole approach depends on the
arbitrary chacteristics of the net, not on any protocols or mandated
net features you can rely on.

Then there is the problem of NATing and or proxying _out_ of the
remote site(s). In fact, most sites will heavily restrict outgoing
connect requests to only a few "legit" priviledged ports. You may not
even be able to use sFTP (but that is less likely). And some sites
consider any unauthorized tunneling out of the site as a clear
violation of policy. And then there is your ISP's traffic policies
re: what appears as automated port scanning.

Re: SMB
Let us count the ways this service can/is abused to gain root/admin
access. It keeps several ports open that provide "direct" access to
security info unless _very_ carefully set up and monitored. It was
never designed as a secure protocol but is embedded in the very stuff
that provides security/authentication. A different design but the
same results when using NFS over a public, untrusted network (a.k.a.
the Internet).

Last, but certainly not least. Of all the files to be accessed over
the Internet, config files and logs are certainly, absolutely, without
a question, no doubt about it the _very_ worst thing you can do. The
only thing worse is to make password and shadow files with world
read/write access.

If after all this you're still wanting/needing access as you describe,
you really should look into setting up a VPN. Your DIY approach will
never be confirmable as safe and once it fails provides an almost
instant access route to admin/root (else how would _you_ get access to
those log and config files?). At least with VPN you'll be working in
several layers of security/encryption.

just my 2c's
prg
email above disabled

> security tricks that are not known to work simply don't

I'd like to use this as an invitation to anyone who wants to discuss the
merits and downfalls of this strategy. Speculation won't cut it.

> The port knocking depends largely on security-thru-obscurity. Anyone
> who does get in will quickly clean up the logs to hide they were ever
> there.

This is true of any break-in. It has nothing to do with the port knocking
mechanism.

> The fact that you will be connecting from only a few subnets
> is also of dubious help -- it only reduces the range of valid IP's
> accepted.

Are you seriously arguing that blocking all but a few subnets is not going
to improve security, noticeably?

> Besides, without an acknowledgement mechanism, there is no
> way know to be certain that the connection attempts will arrive in the
> order that you sent them

I consider this to be a positive point. You could think of it as unreliable,
but I prefer to see it as more reliable because by not acknowledging the
connection attempt, it does not reveal any information about the presence or
absence of a network service. Besides, it is one more layer of security that
is easily logged.

> this whole approach depends on the
> arbitrary chacteristics of the net, not on any protocols or mandated
> net features you can rely on.

If you are referring to timeouts associated with the firewall ruleset, I can
see what you're getting at. This isn't a big issue for me since the places I
plan to connect from do not have a significant latency to my server.

> Re: SMB
> Let us count the ways this service can/is abused to gain root/admin
> access. It keeps several ports open that provide "direct" access to
> security info unless _very_ carefully set up and monitored.

Please back this up with evidence. I'm not going to try to argue that a
Samba installation accessible from anywhere on the internet is a good idea,
but I would be interested to know what security issues it may pose, even if
you exposed ports 137-139 to the whole internet. Assume all shares are
passworded.

> Last, but certainly not least. Of all the files to be accessed over
> the Internet, config files and logs are certainly, absolutely, without
> a question, no doubt about it the _very_ worst thing you can do. The
> only thing worse is to make password and shadow files with world
> read/write access.

I never, ever planned to share log files. You have taken that from the
parent poster who was speculating. The only config files I will be sharing
are personal config files with nothing sensitive in them.

> If after all this you're still wanting/needing access as you describe,
> you really should look into setting up a VPN. Your DIY approach will
> never be confirmable as safe and once it fails provides an almost
> instant access route to admin/root (else how would _you_ get access to
> those log and config files?).

This whole approach will be no less secure than an SSH session.

> At least with VPN you'll be working in
> several layers of security/encryption.

I will look into setting up a VPN, as well. Thanks for your input.


cheers,

C3

So anyway, it was like, 10:01 CET Feb 03 2004, you know? Oh, and, yeah,
C3 was all like, "Dude,

> I never, ever planned to share log files. You have taken that from
> the parent poster who was speculating. The only config files I will
> be sharing are personal config files with nothing sensitive in them.

Just to clarify my "speculations", this is what you wrote:

-----8<-----
More like running programs remotely that write to config/log files in
one place.
----->8-----

You might understand how this does sound like you'll share log files
as well.

> This whole approach will be no less secure than an SSH session.

I disagree, but I'm not going to argue why I think SMB is less secure
than SSH. Your system, your call. I'd still advice against it tho.

>> At least with VPN you'll be working in several layers of
>> security/encryption.
>
> I will look into setting up a VPN, as well. Thanks for your input.

A VPN would definitely be my suggestion as well. You can set up such a
connection point-to-point, assuming that the remote network allows the
ports for it. Given that you were planning to use SMB ports, I'd be
extremely surprised if you'd have a problem getting through on ports
500 et al for IPSec.

--
Time flies like an arrow, fruit flies like a banana. Perth ---> *
10:17:11 up 9 days, 17:53, 3 users, load average: 2.11, 2.11, 2.09
$ cat /dev/bollocks Registered Linux user #261729
embrace visionary channels