Econaut

I can try different USB ports but there's been a recent regression as far as I can tell. Several versions ago this wasn't an issue (or several versions of the plugin ago). Not the controller(s) but a few individual devices, yes. Those are successfully being passed and many preclears have been successful without this issue. I've been able to successfully preclear drives this with non-UASP enclosures a dozen times or so but the past several versions of UNRAID seem to have made this more problematic. Perhaps related but at least one time the unassigned devices plugin dropped nfs/smb shares and needed a reboot. The plugin itself may be part of the issue here.

Ok I got one with that feature and it's the same situation... any ideas?

Alright, confirmed both of mine do not have that.

Same issue as well, tried two different USB 3.0 external drive enclosures. Rebooting gets it working again but then eventually detection fails.

Thirded - it would be awesome if there was a simple way after doing "Stop All" to do "Start All" (which were set to auto start).

I did not! That was it, thanks

I'm on 6.12.3 but cannot see this option to launch remote-viewer - where are they located?

They are updated Ubuntu systems running v4 Checked with nfsstat -s & nfsstat -c Some extra info: UNRAID is NFS server Ubuntu bare metal is one client (haven't actually tested deleting from here, no cause of crash to my knowledge) Ubuntu UNRAID VM is another client (this seems to be where I see the issues the most with deletes and what not) I use UD SMB mounts (no NFS for UD) The bare metal system was seeing stale file handle issues (all NFS clients were) but that issue is passed now.

If possible I'd like to know where in the logs to look to see the crash event from this delete action (or pre-delete action). This was another: Jun 24 06:11:33 REDACTED smbd[12682]: [2023/06/24 06:11:33.404989, 0] ../../source3/smbd/close.c:1485(close_directory) Jun 24 06:11:33 REDACTED smbd[12682]: Could not close dir! fname=REDACTED_FOLDER_PATH, fd=37, err=116=Stale file handle Jun 24 06:11:33 REDACTED smbd[12682]: [2023/06/24 06:11:33.407654, 0] ../../source3/smbd/close.c:1485(close_directory) Jun 24 06:11:33 REDACTED smbd[12682]: Could not close dir! fname=REDACTED_FOLDER_PATH, fd=38, err=116=Stale file handle Jun 24 06:15:52 REDACTED kernel: ------------[ cut here ]------------ Jun 24 06:15:52 REDACTED kernel: nfsd: non-standard errno: -38 Jun 24 06:15:52 REDACTED kernel: WARNING: CPU: 10 PID: 9462 at fs/nfsd/nfsproc.c:889 nfserrno+0x45/0x51 [nfsd] Jun 24 06:15:52 REDACTED kernel: Modules linked in: rpcsec_gss_krb5 cmac cifs asn1_decoder cifs_arc4 cifs_md4 dns_resolver xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle vhost_net vhost vhost_iotlb tap wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha tun xt_nat xt_tcpudp veth xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs nfsd auth_rpcgss oid_registry lockd grace sunrpc md_mod tcp_diag inet_diag it87 hwmon_vid ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge stp llc bonding tls amdgpu radeon gpu_sched drm_ttm_helper ttm btusb edac_mce_amd edac_core gigabyte_wmi wmi_bmof mxm_wmi kvm_amd kvm btrtl crct10dif_pclmul drm_display_helper crc32_pclmul crc32c_intel btbcm ghash_clmulni_intel aesni_intel drm_kms_helper crypto_simd btintel cryptd rapl bluetooth Jun 24 06:15:52 REDACTED kernel: drm igb i2c_piix4 nvme agpgart k10temp i2c_algo_bit ecdh_generic joydev ecc ahci nvme_core i2c_core libahci ccp syscopyarea sysfillrect sysimgblt fb_sys_fops tpm_crb tpm_tis thermal tpm_tis_core video tpm wmi backlight button acpi_cpufreq unix Jun 24 06:15:52 REDACTED kernel: CPU: 10 PID: 9462 Comm: nfsd Not tainted 5.19.17-Unraid #2 Jun 24 06:15:52 REDACTED kernel: Hardware name: MOTHERBOARD INFO Jun 24 06:15:52 REDACTED kernel: RIP: 0010:nfserrno+0x45/0x51 [nfsd] Jun 24 06:15:52 REDACTED kernel: Code: c3 cc cc cc cc 48 ff c0 48 83 f8 26 75 e0 80 3d bb 47 05 00 00 75 15 48 c7 c7 17 24 f0 a0 c6 05 ab 47 05 00 01 e8 42 87 94 e0 <0f> 0b b8 00 00 00 05 c3 cc cc cc cc 48 83 ec 18 31 c9 ba ff 07 00 Jun 24 06:15:52 REDACTED kernel: RSP: 0018:ffffc90002017dc0 EFLAGS: 00010282 Jun 24 06:15:52 REDACTED kernel: RAX: 0000000000000000 RBX: ffff888162b681a0 RCX: 0000000000000027 Jun 24 06:15:52 REDACTED kernel: RDX: 0000000000000001 RSI: ffffffff820d7be1 RDI: 00000000ffffffff Jun 24 06:15:52 REDACTED kernel: RBP: ffff888162b68030 R08: 0000000000000000 R09: ffffffff828653f0 Jun 24 06:15:52 REDACTED kernel: R10: 00003fffffffffff R11: ffff88a05e2bdcdd R12: ffff8882f77de6c0 Jun 24 06:15:52 REDACTED kernel: R13: ffff8881043f4000 R14: 00000000ffffffda R15: ffff8892bd198340 Jun 24 06:15:52 REDACTED kernel: FS: 0000000000000000(0000) GS:ffff889fde280000(0000) knlGS:0000000000000000 Jun 24 06:15:52 REDACTED kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 24 06:15:52 REDACTED kernel: CR2: 000000a98e47efb4 CR3: 0000000160f4c000 CR4: 0000000000750ee0 Jun 24 06:15:52 REDACTED kernel: PKRU: 55555554 Jun 24 06:15:52 REDACTED kernel: Call Trace: Jun 24 06:15:52 REDACTED kernel: <TASK> Jun 24 06:15:52 REDACTED kernel: nfsd_link+0x15f/0x1a5 [nfsd] Jun 24 06:15:52 REDACTED kernel: nfsd4_link+0x20/0x3e [nfsd] Jun 24 06:15:52 REDACTED kernel: nfsd4_proc_compound+0x437/0x56c [nfsd] Jun 24 06:15:52 REDACTED kernel: nfsd_dispatch+0x1a9/0x262 [nfsd] Jun 24 06:15:52 REDACTED kernel: svc_process+0x3f1/0x5d6 [sunrpc] Jun 24 06:15:52 REDACTED kernel: ? nfsd_svc+0x2b6/0x2b6 [nfsd] Jun 24 06:15:52 REDACTED kernel: ? nfsd_shutdown_threads+0x5b/0x5b [nfsd] Jun 24 06:15:52 REDACTED kernel: nfsd+0xd5/0x155 [nfsd] Jun 24 06:15:52 REDACTED kernel: kthread+0xe7/0xef Jun 24 06:15:52 REDACTED kernel: ? kthread_complete_and_exit+0x1b/0x1b Jun 24 06:15:52 REDACTED kernel: ret_from_fork+0x22/0x30 Jun 24 06:15:52 REDACTED kernel: </TASK> Jun 24 06:15:52 REDACTED kernel: ---[ end trace 0000000000000000 ]---

@dlandon Thanks for looking at it. I did recently upgrade the cache to be much larger and it's no longer getting anywhere close to full. The disks remain very full indeed, and I plan to get more but it's what it is for now... Allocation method is High-Water for all. Even with mostly full disks, a delete action shouldn't cause a complete system share meltdown. Min free space settings are all about 100GB or more, should all make sense. Good suggestions for NFS exports. I am no expert either but as UNRAID has limited characters for the rules, I've had to keep it shortened. Thankfully sec=sys should be default and unnecessary to add. I had stale file handle issues and am not sure what helped but removing insecure was one of the things I did. Is it a problem for UNRAID to have NFS mounts/shares only use the 'secure' port(s)? The clients are mounting the nfs shares with fstab options: rw,nosuid,noexec,hard,intr all_squash vs no_root_squash and all that confuses the hell out of me but my choice of `all_squash` to help normalize UID's shouldn't prevent delete from working or cause that to corrupt the UNRAID shares. Got another hard system share meltdown... I sat there wondering if things were stable enough to attempt a delete, started delete, got the popup asking if I was sure, and let it sit there because I was not sure... And there you have it, complete system share meltdown even without a delete being issued. I didn't proceed with the delete but somehow whatever NFS did prior to that prompt is what caused the issue, probably each of the three times this has occurred so far.

Created a file on an NFS share from a linux mount, then deleted the file and all unraid shares crashed and shut down basically. Must restart unraid after that. Issue maybe seems to stem from the permissions of an SMB user being forced into the file system as seen by the NFS mount point... even though I believe I've done all I can to force and normalize users/groups for the files... they just keep changing from nobody. Sounds like a major defect that needs some attention... Is general support not the right place for this?

With some changes, things have been stable comparatively however for the 2nd time, I have deleted a file on an NFS share and this immediately causes UNRAID to drop all shares (seem to all get corrupted in some form) This does not look good and appears to be a major defect of some sort: /mnt# ls -lh /bin/ls: cannot access 'user': Transport endpoint is not connected ... d????????? ? ? ? ? ? user/ ... I have to reboot to get them restored.

Got about a week and it occurred again when trying to delete a file through NFS. Delete failed, then all shares vanished when trying to delete again. Restarted UNRAID and they are back and then I deleted through SMB which worked ok. Seems like NFS is working better with IP(rw,all_squash,anonuid=99,anongid=100) but this issue still happened anyway... what can I do? @JorgeB@itimpi

Same recurring issue with 6.11.5 as well. What are the correct NFS export/mount parameters to avoid this issue? I have a Synology NAS as well with NFS exports and have never run into this issue. Occurs every day, several times a day with UNRAID.

I'd like to see this added as an option as well as I run into the same issues and have no idea how to 'properly' set permissions so SMB/NFS work together well. The New Permissions section always restores order but it would be less of a nuisance if it remained orderly instead.