DOS SMB Client Performance
os2museum.com
os2museum.com
NFS is a lost cause if you want any sort of permissions or security, NFS with Kerberos and AFS are mind-bogglingly complex to set up for a home or small organization, SSHFS is slow, what else is there?
Aside from being "Microsofty", Samba is just a good overall option, and I imagine that's why no-one has really bothered to develop another robust fileserver in the same niche.
A version of that scheme is in the process of being standardized as part of the official NFSv4 protocol: https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-t... (see "Acknowledgments" at the end for a mention of the connection).
My experience with NFS is that permissions fall over the moment you've got root on a box that is allowed to connect. You're essentially relying on network level access control to prevent naughtyness. If I can create a user that has the same UID as someone's files I want on a remote NFS, I can just go do that?
Maybe I've always misconfigured NFS, but as far as I know outside of kerberos there is no way to have independent authorisation of users.
NFSv3 was strictly numeric uid/gid, but this is not the case with NFSv4.
It is still best to keep uid/gid values synchronized, but there are idmapd processes that negotiate permissions between client and server.
Examine the output of "man idmapd.conf" for details. It even does LDAP.
That's impractical in a large organization. They really should have used a username@domain or UUID.
Specifically I wonder if the client is compromised, is it able to start making RPC requests for any arbitrary user (as with AUTH_SYS), or only for any user who uses their own credentials to establish a security context (as with RPCSEC_GSS)?
Forgive my imprecise terminology here, I'm clearly not an NFS/RPC expert! :)
[edit] Ah, I see this is addressed in Sec. 7 - never mind. It looks like you still need to use GSS on top of this scheme in order to prevent a compromised client from impersonating any user.
Minio and s3fs?
TCP vs UDP helps to a limited degree, but has annoying tradeoffs and isn't full proof against the problems.
If you're dealing with unreliable networks, you probably want a remote syncing system as opposed to any rpc oriented remote filesystem. Rclone works remarkably well for that purpose.
In any case asserting that SMB is somehow preferable to any other option is insanity.
I plan on migrating to SMB eventually
Tried NFS for a while but getting permissions to work proved too difficult
Configuring a mesh wireguard network can take some time, though it looks like that's being worked on on and off. The main issue is having to update every config file when a new host joins. On the flip side, having each party authenticate the other means it should be pretty robust.
You can bind NFS to the wireguard interface, and restrict by IP. Wireguard checks public keys against "authorizedips" before forwarding packets, so that should be pretty secure. I added the IPs to `/etc/hosts` so that I could allow a wildcard, that works kind of like netmasks, in a way.
However, it seems not to handle servers coming and going that gracefully.
My other remaining gripe is that there is no mount option to override gid and uid, besides setting up a mapping file; I don't need that granularity.
Now, another option could be 9p (over wireguard), I haven't tried it, but it could be more flexible than NFS.
FWIW the sanest way I've found to configure SMB shares on any OS is Docker on Linux. Concise for common use-cases, rock solid, config won't change out from under you for unclear reasons. I think an underrated benefit of Docker is that it strongly encourages cutting the bullshit out of configuration and getting straight to the point, for what most people want to do with the image. The config lines are gibberish, but at least they're very short gibberish. IIRC one option line per user, one option line per share (maybe one other per share to map the real directory to the container? Can't recall for sure), everything for each of them smushed together on that one line.
No "what kind of user is meant here, again, since there are two kinds?" garbage, no "all three of these options look relevant, but which one is actually being applied in this particular case?" or "which section does this option go in?" that I recall from the hell of trying to configure Samba to do very normal, boring things over the years. 90% of the time all I want is "anonymous read, this username and password for writes, share directories x, y, and z" which is so normal a thing to want to do with it that the config shouldn't occupy much more space than it took to write that out—and, indeed, using the Docker image, it doesn't, and you don't have to deal with outside-the-config user state because the image takes care of that for you, so the config is an easily portable, tiny text file that depends on nothing else but the existence of the directories you're telling it to mount & share, unlike a normal samba config file.
I wonder about the behavior being introduced due to higher CPU speeds. Slowing the VM down to the speed of a machine contemporaneous to the code might yield some insights.
https://www.youtube.com/watch?v=eYxp8yJHpik
Not too shabby !
It would also be interesting to compare performance over protocols other than TCP/IP. The IBM and Microsoft clients both support NetBEUI. I believe one of the Microsoft clients supports NWlink, Microsoft's IPX implementation. And as mentioned above the DEC client supported DECnet.
The hardware token requirement hasn't been worked around yet and sets of Vines disks with hardware tokens can be hard to find. They also sell for hundreds of dollars.
Read about Vines in Byte Magazine - afaik it had something like an enterprise directory which Novell and 3Com Lan Manager did not have.
Long time ago.