5 ms·

As a sysadmin I have always hated SMB. I loved samba for their attempts to opensource it so I could at least use samba4 in prod and feel confident in it's stabi

As a sysadmin I have always hated SMB. I loved samba for their attempts to opensource it so I could at least use samba4 in prod and feel confident in it's stability, but I always felt like it was a bad protocol without many good alternatives. NFS is about the same, even worse when trying to serve to windows clients. For those on linux or not aware, if you see 'cifs' it is the same thing (mostly). One thing I always did was require connections to use latest smb (mitigates many old version attacks), ensure auth is using highest available methods, but more than anything is running the SMB server behind a well monitored and maintained firewall. That's the thing that gets lots of companies. Also, this: https://wiki.archlinux.org/index.php/Samba#Block_certain_file_extensions_on_Samba_share https://wiki.archlinux.org/index.php/Samba#Block_certain_fil... Finally, segment your damn networks with vlans/subnets!

chii 9y ago
so what would be the choice of tech to share files between computers on a private network?
- simcop2387 9y ago
  SFTP/SSH (many IFS and fuse implementations) is an option. But it's not always a good alternative.
  - piyush_soni 9y ago
    Not being knowledgeable enough about these protocols and their relative advantage/disadvantages, can the people who downvoted this comment also write down why to help others? That always makes more sense when it's not obvious.
    - drvdevd 9y ago
      I think this is downvoted because it's considered slow and/or hacky and having a fair amount of overhead (especially for SSH -- e.g. User and Key management). That being said, I think the explanation is not available because ... people aren't really sure about a better option! If we take the common (IMO complex) Network filesystem protocol implementations as having irredeemable flaws (so SMB and NFS, all versions), the only viable contenders I can think of are block level network device protocols. E.g.: iSCSI, NBD, DRBD, and probably quite a few others. These of course have the disadvantage of exposing block level protocols to clients, leaving the actual filesystem management up to the client. Summary: it's always a tradeoff and most of the options suck in one way or another. I personally wouldn't downvote this comment. But maybe someone could enlighten me.
      - piyush_soni 9y ago
        Thanks for the explanation!
      - hollander 9y ago
        What about webdav?
        johansch 9y ago
        WebDav didn't take off because no-one really felt like giving away a high quality implementation in kernel-space for Windows. And Microsoft viewed it as competition against SMB and their licensing model.
    - Spooky23 9y ago
      It's an answer to a problem, but only for a limited number of use cases.
  - Spooky23 9y ago
    These are terrible alternatives once more than a half dozen people are involved. SMB isn't about file transfer so much as the system around authorization and authentication. SSH/SFTP gives you highly secure access to unix file systems. There isn't a good interface to advanced ACLs.
    - simcop2387 9y ago
      Definitely agree, but the grand parent comment wasn't about authorization or authentication. But was about file transfer among a team on a local network. SSH/SFTP gives you that, but as I said it's not always an alternative because of the reasons you mentioned.
- dredmorbius 9y ago
  I'm leaning to some sort of automounter and a secure protocol. What that protocol is ... kind of doesn't matter. If you look at, say, Plan 9 OS, it's got a rather interesting 9P protocol which implements a webfs and ftpfs for local fileshares. What SMB did was, as with much of Windows stuff, conflate a few things: * The filesharing protocol was mixed in with the transport protocol. That's not all bad, as you have that on the Unix world as well (NFS, AFS). But it means you can't change one without dealing with the other (the usual argument against monolithic design). * The mounting and share-discovery mechanism was also baked in. This is where things start bordering on lunacy. In the Unix world, you'd deal with this though an independent mount or automount / autofs system. Which is its own brand of lunacy as well, but.... * Licensing. SMB / CIFS shares carry CALS obligations which I've never been able to comprehend. There are other bits. Like that if you were to access a CIFS share from, say, a Linux box or Cygwin session, each individual process-based access counts as a share (see CALS above, also the per-host session limit of, generally, 10 sessions). Other options: FTP (though it's probably rightfully dying), HTTP, HTTPS (now we're looking at something remotely sensible), SSH. There are FUSE filesystems which will work with each of these, though you've got to specify the hosts. You can automate some of that through autofs (on the Linux / Mac side). WebDAV in theory offers a read/write file-based access over HTTP(S), though in practice it's proved difficult. Generally, this is a space that's oddly lacking in reasonable and good alternatives. I'd argue more generally that documents-based filesystems are also exceptionally poor at what they ought really be capable of doing.
- askvictor 9y ago
  I assume cloud options are out of the question?
- Spooky23 9y ago
  Modern SMB. Version 3 undoes many sins of the past.
- wruza 9y ago
  Web server, suddenly. The need to open and change files right on remote pc (while it is online) always seemed strange, because companies do not work this way. Documents should be received and sent, not mounted and edited silently. I'm sure that there are thousands of info-sharing web projects, from phpbb-likes to specialized light/heavy solutions. But MS sticked to closed, indiagnosable, randomly slow SMB. Traditional file sharing must be killed as an evolution error.
  - tw04 9y ago
    And you're planning on tightly control access to those files in a large organization... how? You're going to write custom apps to do diffs against every file overwrite on upload? And oh, btw, now you've potentially got 200 different copies of the file on various people's laptops. There's a reason why SMB is popular - file sharing among large groups of people who need to modify the files with a web server is a complete nightmare.
    - wruza 9y ago
      People can work on file garbages, I seen that too many times to say otherwise. But once their company starts being non-trash, these actions form into strict processes, responsibilities and access rights anyway. 200 different copies of a file is a red flag of management.
    - ethbro 9y ago
      IMHO, from dealing with it on large corporate client networks, I've never seen SMB solve the problems you mentioned. Either you have an access problem (which you could solve with authentication + authorization in parent's web-based implementation) or you have a modification problem (which is really a revision control problem that I believe SMB doesn't solve at any version?). Which then leads people to tossing everything into Sharepoint (insert tirade here). Which leads to Microsoft not caring about evolving the SMB spec because it would only cannibalize sales. So in essence: SMB cases: "Documents need to be distributed, but not modified by more than one person/team" Revision cases: "Documents need to be distributed, modified by more than one person/team, and redistributed"
mc32 9y ago
Vendors of filers (emc, netapp) aren't the quickest with patching -or smaller shops could be out of support (not recommended but seen it).

chii 9y ago

so what would be the choice of tech to share files between computers on a private network?

simcop2387 9y ago
SFTP/SSH (many IFS and fuse implementations) is an option. But it's not always a good alternative.
- piyush_soni 9y ago
  Not being knowledgeable enough about these protocols and their relative advantage/disadvantages, can the people who downvoted this comment also write down why to help others? That always makes more sense when it's not obvious.
  - drvdevd 9y ago
    I think this is downvoted because it's considered slow and/or hacky and having a fair amount of overhead (especially for SSH -- e.g. User and Key management). That being said, I think the explanation is not available because ... people aren't really sure about a better option! If we take the common (IMO complex) Network filesystem protocol implementations as having irredeemable flaws (so SMB and NFS, all versions), the only viable contenders I can think of are block level network device protocols. E.g.: iSCSI, NBD, DRBD, and probably quite a few others. These of course have the disadvantage of exposing block level protocols to clients, leaving the actual filesystem management up to the client. Summary: it's always a tradeoff and most of the options suck in one way or another. I personally wouldn't downvote this comment. But maybe someone could enlighten me.
    - piyush_soni 9y ago
      Thanks for the explanation!
    - hollander 9y ago
      What about webdav?
      - johansch 9y ago
        WebDav didn't take off because no-one really felt like giving away a high quality implementation in kernel-space for Windows. And Microsoft viewed it as competition against SMB and their licensing model.
  - Spooky23 9y ago
    It's an answer to a problem, but only for a limited number of use cases.
- Spooky23 9y ago
  These are terrible alternatives once more than a half dozen people are involved. SMB isn't about file transfer so much as the system around authorization and authentication. SSH/SFTP gives you highly secure access to unix file systems. There isn't a good interface to advanced ACLs.
  - simcop2387 9y ago
    Definitely agree, but the grand parent comment wasn't about authorization or authentication. But was about file transfer among a team on a local network. SSH/SFTP gives you that, but as I said it's not always an alternative because of the reasons you mentioned.
dredmorbius 9y ago
I'm leaning to some sort of automounter and a secure protocol. What that protocol is ... kind of doesn't matter. If you look at, say, Plan 9 OS, it's got a rather interesting 9P protocol which implements a webfs and ftpfs for local fileshares. What SMB did was, as with much of Windows stuff, conflate a few things: * The filesharing protocol was mixed in with the transport protocol. That's not all bad, as you have that on the Unix world as well (NFS, AFS). But it means you can't change one without dealing with the other (the usual argument against monolithic design). * The mounting and share-discovery mechanism was also baked in. This is where things start bordering on lunacy. In the Unix world, you'd deal with this though an independent mount or automount / autofs system. Which is its own brand of lunacy as well, but.... * Licensing. SMB / CIFS shares carry CALS obligations which I've never been able to comprehend. There are other bits. Like that if you were to access a CIFS share from, say, a Linux box or Cygwin session, each individual process-based access counts as a share (see CALS above, also the per-host session limit of, generally, 10 sessions). Other options: FTP (though it's probably rightfully dying), HTTP, HTTPS (now we're looking at something remotely sensible), SSH. There are FUSE filesystems which will work with each of these, though you've got to specify the hosts. You can automate some of that through autofs (on the Linux / Mac side). WebDAV in theory offers a read/write file-based access over HTTP(S), though in practice it's proved difficult. Generally, this is a space that's oddly lacking in reasonable and good alternatives. I'd argue more generally that documents-based filesystems are also exceptionally poor at what they ought really be capable of doing.
askvictor 9y ago
I assume cloud options are out of the question?
Spooky23 9y ago
Modern SMB. Version 3 undoes many sins of the past.
wruza 9y ago
Web server, suddenly. The need to open and change files right on remote pc (while it is online) always seemed strange, because companies do not work this way. Documents should be received and sent, not mounted and edited silently. I'm sure that there are thousands of info-sharing web projects, from phpbb-likes to specialized light/heavy solutions. But MS sticked to closed, indiagnosable, randomly slow SMB. Traditional file sharing must be killed as an evolution error.
- tw04 9y ago
  And you're planning on tightly control access to those files in a large organization... how? You're going to write custom apps to do diffs against every file overwrite on upload? And oh, btw, now you've potentially got 200 different copies of the file on various people's laptops. There's a reason why SMB is popular - file sharing among large groups of people who need to modify the files with a web server is a complete nightmare.
  - wruza 9y ago
    People can work on file garbages, I seen that too many times to say otherwise. But once their company starts being non-trash, these actions form into strict processes, responsibilities and access rights anyway. 200 different copies of a file is a red flag of management.
  - ethbro 9y ago
    IMHO, from dealing with it on large corporate client networks, I've never seen SMB solve the problems you mentioned. Either you have an access problem (which you could solve with authentication + authorization in parent's web-based implementation) or you have a modification problem (which is really a revision control problem that I believe SMB doesn't solve at any version?). Which then leads people to tossing everything into Sharepoint (insert tirade here). Which leads to Microsoft not caring about evolving the SMB spec because it would only cannibalize sales. So in essence: SMB cases: "Documents need to be distributed, but not modified by more than one person/team" Revision cases: "Documents need to be distributed, modified by more than one person/team, and redistributed"

mc32 9y ago

Vendors of filers (emc, netapp) aren't the quickest with patching -or smaller shops could be out of support (not recommended but seen it).