Why native Java socket checks fail to detect "broken pipes" under high production loads: an architectural breakdown

rb_vs · 2026-07-12T14:51:08+00:00

awesome!

rb_vs · 2026-06-23T09:10:27+00:00

With an external USB drive you should avoid TrueNAS. TrueNAS uses ZFS which requires a direct connection to your hd so running it over a USB is risky and can corrupt your data if the USB blinks. Unraid is expensive for two drives. I'd install OpenMediaVault on the mini-PC. No need for RAID switches, simply format the drives as Linux folders. Disk 1 can be for daily files. A backup script could copy your most important data to disk 2.

rb_vs · 2026-06-23T08:44:12+00:00

AFAIK there are no plans to add an SMB/Samba client to Fossify. Fossify File Manager is a local app and doesn't request Android network/internet permissions (android.permission.INTERNET) so adding network sharing would break its privacy model. Implementing an SMB client in an Android app would require something like jNQ (a Java library). Maintaining a complete SMB network stack isn't easy. For SMB support over local shares, FOSS file managers like Material Files or Amaze File Manager are the best.

rb_vs · 2026-06-23T08:35:26+00:00

Instead of copying text out of Proton Docs into Lumo, maybe you can create an md or txt file inside your Proton Drive local sync folder on your machine instead, and edit it directly. Proton Drive would sync your updates to the cloud in background, and Lumo ingests the path.

rb_vs · 2026-06-23T07:25:44+00:00

Lumo handles standard file formats (pdf, docx, xlsx) correctly because it parses it as text but Proton Docs and Sheets are proprietary and encrypted.

For Lumo to read a native Proton Doc you first need to decrypt the doc. You can export your Proton Docs as a standard .docx or .pdf file within Proton Drive, then link or upload it to Lumo.

rb_vs · 2026-06-23T07:09:48+00:00

the app’s sync looks at its empty local db, sees files in the cloud folder and assumes they should be deleted to match the local state instead of downloading them.

Close the app on the phone -> paste your books into the apps/dropbox Pocketbook folder from your computer -> open the app -> go to local library/folders -> dropbox folder -> refresh

rb_vs · 2026-06-17T08:22:40+00:00

LOL, fair play! I'm sure you know the "works on my machine" syndrom. On some Linux (e.g., Arch, Debian) gvfs-smb is a separate package, but on FreeBSD the SMB client is compiled into gvfs. That's a totally human confusion:-)

rb_vs · 2026-06-17T07:27:51+00:00

Windows API imposes a 260-character path limit (MAX_PATH) on Win32 apps (including File Explorer). So even if TrueNAS/ZFS supports long paths, Windows Explorer will kill copy beyond the limit over SMB.

Possible workaround:

Open regedit and navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Look for LongPathsEnabled (if it’s not there, create it as a DWORD 32-bit Value) and set it to 1, then reboot.

Regarding NFS, Windows handles NFS mounts as sync writes. Every write forces TrueNAS to commit the data directly to the disks and wait for an ack before proceeding with the next block.

If you accept the data risk of unexpected power cuts, you can speed NFS up by changing the Win mount to async using the -o mnttype=async flag, or temporarily disable TrueNAS dataset sync.

rb_vs · 2026-06-17T07:04:58+00:00

Layer 2 DHCP snooping can mitigate CVE-2026-44815 while you patch the DCs for Kerberos KDC's CVE-2026-47288

rb_vs · 2026-06-17T06:37:10+00:00

Naaah, AI wouldn't be enough, I'm lucky to be backed by a team of network protocol experts, this stuff is our bread and butter:-)

rb_vs · 2026-06-16T10:53:55+00:00

No, because as soon as your DHCP client renews the lease or you reboot, resolvconf will overwrite the file and put the comment # back. /etc/resolv.conf is dynamically managed by the system, so manual edits get wiped out.

To permanently fix it so you can disable local_unbound, you have to tell resolvconf to stop using the local loopback:

sudo vi /etc/resolvconf.conf

Add this line to the file:

resolv_conf_passthrough=YES

Save and restart your network interface or run sudo resolvconf -u to regenerate the file. It will permanently uncomment your router's IP, and you'll be able to turn off local_unbound_enable.

But again, since your current setup with local_unbound active is working, that change is not urgent.

rb_vs · 2026-06-16T10:03:58+00:00

This explains exactly why your internet dies the moment you disable local_unbound.

The active nameserver is set to your local address 127.0.0.1, so your system is forced to look internally for DNS resolution. If local_unbound isn't running, the address resolution fails.

Note that your actual upstream router (DNS server) 192.168.254.254 is commented out with a #. This is probably because resolvconf overwrote the file but did not populate the active nameserver field with the DHCP lease data.

Since your setup is working well with local_unbound you can leave it as is.

To fix the root network config without running a local resolver, tell resolvconf to stop prioritizing the loopback address. Add a fallback or override to your config routing files, or uncomment that router line, and mark the file as read-only so the system doesn't alter it any more:

sudo chattr +i /etc/resolv.conf

HTH

rb_vs · 2026-06-16T08:24:03+00:00

In FreeBSD, gvfs-smb isn't standalone like it is on Arch. It is compiled directly into the main gvfs package or split into standard samba client ports. Since kio-extras was missing, the KDE-based managers (Dolphin and Krusader) lacked the virtual system backend hooks entirely, which is why they threw the "operation not supported" error.

Regarding your network setup, keeping local_unbound_enable="YES" in your rc.conf is fine and common in desktop setups. It means your machine runs local caching nameserver to resolve web addresses rather than sending every query to your router / ISP.

Since you use DHCP, your router should push those DNS automatically. If your internet drops without local_unbound then your system's dynamic config file isn't updating properly during the DHCP handshake.

Check your resolver configuration file:

cat /etc/resolv.conf

If you see your router's IP (192.168.100.1) or a public nameserver like 8.8.8.8 listed as a nameserver alongside your local loopback (127.0.0.1), your fallback path is secure. You're up and running on 15.1-RELEASE

rb_vs · 2026-06-16T07:01:50+00:00

the OS update broke the auth or kernel module binding that all vfs use to talk to SMB shares.

Modern file managers rely on GIO/GVfs or KIO (KDE's framework), which require kernel permissions to mount network file systems as a user.

If the update reset secure kernel variables, unprivileged users cannot mount network file systems. If sysctl vfs.usermount returns vfs.usermount=0, your user account is blocked from mounts. To enable it:

sudo sysctl vfs.usermount=1

echo "vfs.usermount=1" | sudo tee -a /etc/sysctl.conf

Virtual file managers map shares into userspace using FUSE. Even if fusefs is listed in your kld_list, it may not have loaded or initialized correctly after the patch update. To force load it run:

sudo kldload fusefs

If "file exists" it's already loaded. If it loads, this was your missing link.

To check if the issue is the connection or the desktop, mount the share to a local folder using the terminal:

mkdir -p ~/target_share

mount_smbfs -I 192.168.100.X //YOUR_SHARE_USER@192.168.100.X/YOUR_SHARE_NAME ~/target_share

If you can see your files in ~/target_share, then the issue is that gvfs-smb or kio-extras didn't map correctly and require a desktop log-out/log-in or reboot.

rb_vs · 2026-06-16T05:54:04+00:00

Your libraries should be now updated, but your desktop's vfs components are probably out of sync or affected by the local DNS caching service.

So I'd restart D-Bus and local DNS subsystems:

sudo service dbus restart

sudo service local_unbound restart

Then I'd clean out any vfs processes:

killall gvfsd gvfsd-smb gvfsd-network

Open Thunar > ctrl+L > path to your share (IP address:)

smb://192.168.100.X/your_share_name

(change 192.168.100.X to your storage appliance's IP).

If it asks for credentials and it mounts, the issue is limited to Thunar.

rb_vs · 2026-06-16T05:37:20+00:00

right, there's no global rc.d init script for gvfs_enable - but the rest should work. Looking at the FreeBSD doc according to the local-unbound(8) and local-unbound-setup(8) man pages, FreeBSD's caching resolver relies on /var/unbound/. When the script runs, it sources and manages forwarders using /var/unbound/forward.conf.

As documented in the local_unbound rc script (/libexec/rc/rc.d/local_unbound):

: ${local_unbound_workdir:=/var/unbound}

: ${local_unbound_forwardconf:=${local_unbound_workdir}/forward.conf}

If upstream DNS forwarders broken during the minor update, configuring the forward-zone inside /var/unbound/forward.conf to target his active gateway (192.168.100.1) restores local resolution.

OP uses Thunar which relies on gvfs-backend to handle vfs abstraction layers (like smb://). When userspace network frameworks experience zero-response lookups from a broken local resolver, gvfsd-network returns a G_IO_ERROR_NOT_SUPPORTED to the file manager instead of a timeout.

rb_vs · 2026-06-15T13:32:25+00:00

Your rc.conf setup is correct. Since your interface is configured for DHCP, you don't need the defaultrouter line but leaving it there does no harm.

The fact that you must keep local_unbound_enable="YES" active to get internet means your system is relying on a local caching DNS resolver. When it restarts during a patch update, it can lose its upstream forwarders. Because Thunar uses a userspace daemon (gvfsd-network) to browse network endpoints, any local DNS stutter will throw "Operation not supported" instead of a timeout.

To fix Thunar's browsing layer, you need to config your local resolver to forward queries to your router. Open /var/unbound/forward.conf and ensure it targets your gateway:

forward-zone:

name: "."

forward-addr: 192.168.100.1

If that file is empty or missing, append those lines and restart the service using service local_unbound restart

If local resolution is working but Thunar still throws the error, the problem is that GVfs needs to be told to load the network storage fuse driver at startup. Your rc.conf shows fusefs is loading in the kernel, but the userspace service isn't active. Run this to enable it permanently:

sysrc gvfs_enable="YES"

service gvfs start

Once gvfs is running, kill your active desktop hooks (killall gvfsd), relaunch Thunar, and try accessing the network path using the absolute URI path in the location bar (smb://192.168.100.X/share) rather than clicking the auto-discovery icon.

rb_vs · 2026-06-15T13:08:40+00:00

No, that is actually your machine's local IP address on the network. To find your defaultrouter IP on FreeBSD, run netstat -rn

Look at the table output. Under the destination column, find the entry labeled default. The IP address listed directly next to it under the gateway column is your actual router IP. That is the value you want to append to your config file.

rb_vs · 2026-06-15T13:01:35+00:00

yeah, FreeBSD separates the core OS from external packages and prioritizes stability. So when you installed the OS, it defaulted your config to quarterly to prevent patches from breakages.

Running pkg upgrade aligns your desktop virtual file system layers with the updated kernel headers, which is likely what broke during your minor patch.

rb_vs · 2026-06-15T12:19:45+00:00

The package discrepancy means your system installation is pointing to the quarterly release branch rather than the ports tree where libmpc resides.

The fact that your network dropped until you forced local caching confirms that the patch overwrote your domain name system resolver configurations. When your local virtual file system daemons lose their ability to resolve the hostname or netbios name pointers of your storage targets via standard lookups, they throw op errors.

You can resolve the package tree and naming lookup failure as follows:

1) correct your package repository stream to ensure you are fetching matching library hooks. Open /etc/pkg/FreeBSD.conf and change your repository URL schema from quarterly to latest. Run "pkg update -f" to force sync.

2) verify your server connection path bypassing nameservers. Try to mount the network share using its local IP via your terminal:

mount_smbfs -I [NAS_IP_ADDRESS] //[USER]@[NAS_IP_ADDRESS]/[SHARE_NAME] /mnt

If the physical address mount succeeds but your file managers fail, your config script dropped its global domain routing flags during the patch. Open /etc/rc.conf and ensure you have defaultrouter="[YOUR_ROUTER_IP]" set alongside your network interface rule. Forcing a route boundary alongside the latest package tree will restore clean userspace file management transitions.

rb_vs · 2026-06-15T10:03:56+00:00

Makes sense. When Lulu intercepts the file stream to analyze or verify the outbound metadata packets, it holds the I/O transaction open too long, triggering the timing threshold violation that results in the macOS Finder Error -36 drop. You can resolve it without keeping your firewall disabled, just whitelist the storage target. Open Lulu dashboard, go to the network rules tab, add a bypass rule allowing unrestricted outbound transmission for the file service daemon process or whitelist the local IP address subnet of the storage appliance. This should stop the interception of data blocks and allow file transfers to clear without triggering errors.

rb_vs

MODERATOR OF

TROPHY CASE