So I recently muxed a bluray with mkvmerge, and proceeded to copy it to my nas with proxmox and cockpit smb server with a mount bind passed through from my host zraid.
I have 500 files on here, and have had a similar issue once before with a different movie mux file (ignored back then). I’m on Ublue Aurora fedora. Shares are smb mounted locally.
What happens is this: I copy the file, it gets to 100% and hangs. The proxmox smbd spawns a ton of PIDs and the unprivileged LXC wont shutdown or stop until the host is rebooted (which takes 5 mines of slow waiting). All 4 cores mapped to the lxc get pegged to 100% and adding 2 more for a total of 6 pegs those too.
After rebooting, copying the file again will cause the issue every time. I have another cockpit smb NAS on a privileged container on entirely different hardware, different setup that does the same exact thing when I copy this remux file. The file copies over fine to an SMB QNAP share. Copies over fine from a windows box to the Proxmox NAS, so isolated to the dolphin file copy or mkvmerge mux copy on Fedora to Proxmox LXC smb share.
I assume it’s something with Fedora and this file, but don’t know what it is. The machine froze afterwards once, so I’m wondering if it’s bad ram potentially. 128GB off brand ECC.
Anyone experienced something similar before?
Do you have xattr fixed for the underlying zfs?
It’s on sa, so ok.
I had something similar happen with a DVD iso. It would not copy across network, and cpu would skyrocket if I put it on drive another way. For mine it turned out to be the tracker-miner getting hung up on the content indexing. Specifically it was a DVD with a prank menu option. The menu option was “Break my player” which if you chose it would totally lock the DVD player and only fix was unplugging it for a hard power cycle. Somehow whatever code did that was messing with the content indexer
whatever code did that was messing with the content indexer
Those guys were determined you’d get what was on the tin, no matter what
You’ve probably got a filesystem flag off somewhere in this chain of mounts. It sounds like the handoff from smb to filesystem has an issue.
Possibly similar: https://github.com/openzfs/zfs/issues/14391
This is what I’m thinking. The file originally overwrote an older one, I muxed in and synced truehd audio into the original and ended up copying it back after forgetting a subtitle track. It definitely went back and forth with the same name a few times. It’s probably something with the Unix ACLs. Still concerning that it crashes the SMB daemon.
I would honestly run network services closest to the OS to avoid any issues. If it goes away, there ya go. If not, start digging at Samba+Docker+ZFS config options.