💾 Archived View for michaelsteele.us › gemlog › it › 2022012801.gmi captured on 2024-03-21 at 14:59:49. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
it
It can be surprising when one encounters a technical problem which seems like it should be an ordinary thing, yet no solution stands out as obvious. You go looking for blogs or articles and find nothing useful. There must be someone out there who has dealt with this, yet apparently not frequently enough for anybody to write about it.
This is the situation I ran into this week. I have a physical computer running FreeBSD, and I need a way to write data to a Windows computer where it can be backed up. Specifically, I want to back up my FreeBSD computer to a Borg Backup repository hosted on Windows.
At first I assumed that SMB would be the way to go. Doesn't everyone use SMB when sharing files between UNIX-likes and Windows? It turns out that FreeBSD only has native support for SMB1. This original version of SMB is no longer considered safe to use. Microsoft recommended disabling it a few years ago, and I don't think it is supported at all by recent versions of Windows.
Apparently there is a way to use FreeBSD as an SMB2/3 client. You can install Samba, and make use of its client along with a certain FUSE driver to mount a folder. The performance is quite poor from what I read, and it seems like a clunky solution. There has to be a better option.
Besides SMB, the other network file sharing protocol I often hear about is NFS. My impression is that the protocol hasn't been widely used for at least a few decades, but I'm aware that it has undergone continued development all this time. I experimented with NFS some years ago when I was sharing files between a Linux computer and a Linux-based NAS. The file sharing itself worked as expected, but I needed to manually map user and group ID numbers between the two systems. It ended up being easier to use SMB, which was rather a shame.
Well, Microsoft advertises robust support for NFS. They support NFS version 4.1 with integrated Kerberos authentication, encrypted transit, and NFSv4 ACLs. Sounds great! FreeBSD supports all of that as well, I thought, so this should be the perfect solution.
It turns out that Microsoft's NFS server is borderline useless, and I suspect this is by design. If you search around, you will find many articles going through the process of setting up an NFS Windows share. The articles will be nearly identical to each other, going so far as to use the same screenshots. Windows is able to host NFS shares as advertised, and you can mount them on FreeBSD. You just can't use them for anything.
Microsoft implement all of the mandatory components of NFS version 4, and handled the optional components in a surprising way. The best example, and really the only example I need to share, is how they handled ACLS.
Windows file permissions make heavy use of access control lists, and these are largely analogious to NFSv4 ACLs. In Windows you are able to assign permissions to a folder, and those permissions apply to any files or subfolders within it. It is possible to manually assign permissions to each file and each folder, but this is combersome and not the way you handle permissions in Windows.
When Windows shares a file over NFS, inherited permissions do not apply. Any files you populate in Windows will be inaccessible by the client unless you manually assign a permission entry directly on that file or folder. Any files you create by the client will become immediately inaccessible by that client until you manually assign a permission on the host. I don't see any way around this problem. Windows says they support NFSv4 ACLs, but they implemented it in such a way that it is simply not usable.
A work around might be to turn off Kerberos authorization, and revert to an older version of NFS. If you do this, you lose encrypted transport and strong authentication. It's always frustrating when a product or service gets you 90% of the way to where you want to be.
I ended up finding a solution that should work well. Microsoft added a port of OpenSSH server for Windows. It support SCP and public key authentication, but strangely it does not support GSSAPI (Kerberos authentication). FreeBSD has an sshfs FUSE driver which allows you mount a file system that uses SCP behind the scenes. It is likely slower than SMB or NFS would have been, but I will gladly go with a solution that is simple.
Microsoft's documentation does not explain all of the requirements, but it got me far enough along to fill in the blanks. Here are the steps you need to follow from the Windows side:
1. Install OpenSSH server. There is a PowerShell incantation you can use if you are on Windows Server 2019 or later. That PowerShell command will report 'success' on Windows Server 2016, but then the software won't actually work. For older versions of Windows, there is a Github page where you can download the software.
2. Register the 'sshd' service to start automatically.
3. Select which Windows user account you wish to use for the file access, and sign in as that user at least once. I used a one-off service account.
4. Create an ".ssh" folder within that user's home directory. The File Explorer will not let you do this, but you can create folders with a leading '.' character from the command prompt.
5. Generate an SSH key from your FreeBSD computer.
6. Write an ".ssh\authorized_keys" file in that folder. Be sure that only SYSTEM, Administrators, and your user account has access to the file.
I stumbled on steps 1, 2, and 6 before sucessfully signing in using a public key.
My struggles with NFS on Windows was quite frustrating, but in the end I think that SSHFS is a better solution which I would not have arrived at had NFS given me less trouble.
2022-01-28