Ok boys, I got some results back after some testing.
1. Don't rely on restarting
after modifying the .conf file and expecting everything to refresh nicely. I found that a full system reboot on both machines
is needed (aka, not a log out/in) to get proper sharing views refreshed in order after a change to the config.
2. Firewall rules. For those of you with custom rules: client needs to allow server (tcp 139, 445) and bcast address (udp 137-138) on the network. (The avahi-daemon might use 2 other udp ports so be sure to check.) The bcast address isn't needed if you want to access shares directly via IP (versus the resolved netBIOS name) -- I found this by accident but was happy about it because see #3 below. (The address to access the shares in caja is simply:
.) Server needs to allow client address and nothing else. For the 98% of you without custom rules, the shares should work (provided gufw is disabled or is allowing incoming connections
) -- no modification to ufw is necessary.
3. Disabling printer sharing. I'm happy to report that the code in my previous post works and the syslogs are no longer spammed by constant messages from the
. However, enabling the code on the server kills the list of netBIOS names of the devices in your "browse network" view. Here's when you can access devices (and their list of shares) directly by their network IP as explained in #2 above. If you want the netBIOS names back, then don't add the code to the server's config (and suffer the consequences of a spammed syslog on the server side.)
4. Encryption. I did some more research on this and came up with various results. Apparently the default option is "auto" but I haven't found if "auto" == "preferred" and if both machines would indeed use encrypted connections if both are on auto. Thankfully there is an option to force it:
smb encrypt = mandatory
(again in the
section), however using this on the server side gave me the following very, very weird error when setting up any usershare:
'net usershare' returned error 255: net usershare add: cannot convert name "Everyone" to a SID. Access denied.
So, I scrapped this option on the server and the client seems fine with it enabled. (I assume through logic here that a "mandatory" encrypted connection would not be made if the server wouldn't allow it -- if not, this
is a horrible bug. Really needs to be tested with tcpdump.) It's worth noting here that a mandatory connection should really be made in your setup because various security issues in the recent past have recommended you have this setting enabled
as a "workaround for the bug now." P.S. I also found out
that connections to cups are not
encrypted by default. This really makes the case to disable printers in #3 or set
cups encrypt = auto
(Default: "no") for at least a minimal TLS handshake to printers (and available printer drivers) on the network. Bad!
5. Transfer speed and folder views. Some momentary drops from hdd ext4 to ssd ext4 (both fde) but hdd ext4 to hdd ntfs (both fde) was solid at ~60MB/s sustained on a 5GB file. So doing a dumb calculation that's about 48% of theoretical on a gigabit connection with the layered encryption overhead, which is pretty good. CPU utilization wasn't bad at all either. Shares are still listed (but not accessible) to the client if the shared folders are moved to the trash and also if the trash is emptied (lol.) Manually f5 refreshing either the list of shares to mount or the network names occasionally hangs caja to the point where you need to force quit
-- I can't reproduce the issue but it seems to happen after a reboot and a first view in the network folder -- I'd recommend not manually refreshing in the "Browse Network" view. If you force quit
, the "file operations" transfer speed box will stay blank for the remaining login session (but will still transfer normally.)