FreeBSD 13.1: SMB > v1 / samba / cifs shares

Hi there.

Since base does not support mounting anything more recent than SMBv1, I installed fusefs/smbnetfs. For starters, I went as follows after installing the package on FreeeBSD 13.1:

Code:
# kldload fusefs
# sysctl vfs.usermount=1

% mkdir ~/smbmounts
% smbnetfs ~/smbmounts
% cd ~/smbmounts/USERNAME:PASSWORD@IP-ADDR

I am connecting to a samba412-4.12.15_3 server running on FreeBSD 13.0, and am not using any configuration files for now.

That seems to work, albeit quite erratical, I do get timeouts, shell completion (and matching) does not work reliably, and I can't find a way to "undo" the smbnetfs command in order to remove ~/smbmounts. The directory is always "busy" when I try to unlink it.

Any users of fusefs/smbnetfs around able to provide pointers ? I'm happy to provide more information and run tests.

Edit: As SirDice pointed out, the ancient technique of unmounting a filesystem before trying to remove its mountpoint does the trick.
 
As unfortunate as it is, in my experience, none of the fuse-based implementations is "production quality". It's okayish if you need to access some SMB share "ad hoc", but it's nothing you should rely on in normal operation of your system.

Even if there was a "perfect" implementation, it would still suffer from the performance penalty that's unavoidable with fuse.

As long as there's no SMB2+ support in base, FreeBSD isn't suitable as an SMB client. If you can, offer shares via NFS instead (or additionally). If that isn't an option, for now, a different client OS would be more suitable :(
 
As unfortunate as it is, in my experience, none of the fuse-based implementations is "production quality". It's okayish if you need to access some SMB share "ad hoc", but it's nothing you should rely on in normal operation of your system.

Even if there was a "perfect" implementation, it would still suffer from the performance penalty that's unavoidable with fuse.

As long as there's no SMB2+ support in base, FreeBSD isn't suitable as an SMB client. If you can, offer shares via NFS instead (or additionally). If that isn't an option, for now, a different client OS would be more suitable :(
That is indeed unfortunate. In most environments, Samba seems to be the most convenient common denominator and sometimes the only file sharing service offered, so while I have a choice for environments I am in control of, I don't in others.

For now, apart from these inconveniences, and with the limited testing I did, I've not experienced any data corruptions with smbnetfs, which were my main concern after experiencing some of the oddities.
 
Back
Top