traciemiglionico

Hi everyone, I'm encountering a rather perplexing issue and I'm reaching out for some assistance. My setup involves a computer running Windows Server 2022, accessing a SMB share provided by the Unraid(6.12.3) server through network sharing. While the setup generally works seamlessly, there's an intermittent occurrence of an EventID 129 error on that Windows Server, that's been causing some concern. I'm eager to comprehend the root of this error and explore potential solutions. Here's a more detailed breakdown of my configuration: Windows Server 2022 is in use, with network sharing configured and functioning. The purpose is to access a SMB share hosted on the Unraid server. An interesting observation is as follows: When the corresponding shared directory is located within the SSD pool on the Unraid server, the EventID 129 error does not manifest. However, when this directory is situated within the HDDs Array, or within the ZFS pool, there's a noticeable probability of triggering the EventID 129 error. The exact wording of the EventID 129 error message is as follows: Reset to device, \Device\RaidPort0, was issued. - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="storahci" /> <EventID Qualifiers="32772">129</EventID> <Version>0</Version> <Level>3</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2023-08-29T03:17:46.3990598Z" /> <EventRecordID>96359</EventRecordID> <Correlation /> <Execution ProcessID="4" ThreadID="12124" /> <Channel>System</Channel> <Computer>server2k22</Computer> <Security /> </System> - <EventData> <Data>\Device\RaidPort0</Data> <Binary>0F001800010000000000000081000480010000000000000000000000000000000000000000000000000000000000000001000000810004800000000000000000</Binary> </EventData> </Event> I'm curious whether anyone else within the community has encountered a similar scenario. If so, I would greatly appreciate any insights, strategies, or suggestions you might have to offer. Thank you kindly for your time and assistance in advance!

Jun 24 04:50:02 AtomNas rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="983" x-info="https://www.rsyslog.com"] rsyslogd was HUPed Jun 24 12:35:13 AtomNas emhttpd: shcmd (1031): /usr/local/sbin/mover |& logger & Jun 24 12:35:13 AtomNas root: mover: started Jun 24 12:35:13 AtomNas root: Cannot stat file /proc/25487/fd/42: Stale file handle Jun 24 12:35:13 AtomNas move: file: pathA /************** repeat the 'Cannot stat file /proc/25487/fd/42: Stale file handle' and 'move: file: path*' about tens different paths *******************/ Jun 24 13:07:29 AtomNas root: mover: finished Jun 26 23:57:57 AtomNas smbd[25487]: [2023/06/26 23:57:57.459082, 0] ../../source3/smbd/close.c:1397(close_directory) Jun 26 23:57:57 AtomNas smbd[25487]: close_directory: Could not get share mode lock for /other path (other path not include path*) Jun 26 23:57:57 AtomNas smbd[25487]: [2023/06/26 23:57:57.459121, 0] ../../source3/smbd/fd_handle.c:39(fd_handle_destructor) Jun 26 23:57:57 AtomNas smbd[25487]: PANIC: assert failed at ../../source3/smbd/fd_handle.c(39): (fh->fd == -1) || (fh->fd == AT_FDCWD) Jun 26 23:57:57 AtomNas smbd[25487]: [2023/06/26 23:57:57.459131, 0] ../../lib/util/fault.c:173(smb_panic_log) Jun 26 23:57:57 AtomNas smbd[25487]: =============================================================== Jun 26 23:57:57 AtomNas smbd[25487]: [2023/06/26 23:57:57.459143, 0] ../../lib/util/fault.c:174(smb_panic_log) Jun 26 23:57:57 AtomNas smbd[25487]: INTERNAL ERROR: assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in pid 25487 (4.17.3) Jun 26 23:57:57 AtomNas smbd[25487]: [2023/06/26 23:57:57.459151, 0] ../../lib/util/fault.c:178(smb_panic_log) Jun 26 23:57:57 AtomNas smbd[25487]: If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting Jun 26 23:57:57 AtomNas smbd[25487]: [2023/06/26 23:57:57.459159, 0] ../../lib/util/fault.c:183(smb_panic_log) Jun 26 23:57:57 AtomNas smbd[25487]: =============================================================== Jun 26 23:57:57 AtomNas smbd[25487]: [2023/06/26 23:57:57.459167, 0] ../../lib/util/fault.c:184(smb_panic_log) Jun 26 23:57:57 AtomNas smbd[25487]: PANIC (pid 25487): assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in 4.17.3 Jun 26 23:57:57 AtomNas smbd[25487]: [2023/06/26 23:57:57.459546, 0] ../../lib/util/fault.c:292(log_stack_trace) Jun 26 23:57:57 AtomNas smbd[25487]: BACKTRACE: 31 stack frames: Jun 26 23:57:57 AtomNas smbd[25487]: #0 /usr/lib64/libgenrand-samba4.so(log_stack_trace+0x2e) [0x14ae453ed64e] Jun 26 23:57:57 AtomNas smbd[25487]: #1 /usr/lib64/libgenrand-samba4.so(smb_panic+0x9) [0x14ae453ed8a9] Jun 26 23:57:57 AtomNas smbd[25487]: #2 /usr/lib64/libsmbd-base-samba4.so(+0x4d10b) [0x14ae457ce10b] Jun 26 23:57:57 AtomNas smbd[25487]: #3 /usr/lib64/libtalloc.so.2(+0x44df) [0x14ae4539d4df] Jun 26 23:57:57 AtomNas smbd[25487]: #4 /usr/lib64/libsmbd-base-samba4.so(file_free+0xd6) [0x14ae457db2e6] Jun 26 23:57:57 AtomNas smbd[25487]: #5 /usr/lib64/libsmbd-base-samba4.so(close_file_free+0x29) [0x14ae4580bd49] Jun 26 23:57:57 AtomNas smbd[25487]: #6 /usr/lib64/libsmbd-base-samba4.so(+0x5d046) [0x14ae457de046] Jun 26 23:57:57 AtomNas smbd[25487]: #7 /usr/lib64/libsmbd-base-samba4.so(+0x5d1ce) [0x14ae457de1ce] Jun 26 23:57:57 AtomNas smbd[25487]: #8 /usr/lib64/libsmbd-base-samba4.so(files_forall+0x19) [0x14ae457da119] Jun 26 23:57:57 AtomNas smbd[25487]: #9 /usr/lib64/libsmbd-base-samba4.so(file_close_user+0x3d) [0x14ae457da25d] Jun 26 23:57:57 AtomNas smbd[25487]: #10 /usr/lib64/libsmbd-base-samba4.so(smbXsrv_session_logoff+0x4d) [0x14ae4585700d] Jun 26 23:57:57 AtomNas smbd[25487]: #11 /usr/lib64/libsmbd-base-samba4.so(+0xd6677) [0x14ae45857677] Jun 26 23:57:57 AtomNas smbd[25487]: #12 /usr/lib64/libtevent.so.0(tevent_common_invoke_immediate_handler+0x17a) [0x14ae453b0cfa] Jun 26 23:57:57 AtomNas smbd[25487]: #13 /usr/lib64/libtevent.so.0(tevent_common_loop_immediate+0x16) [0x14ae453b0d16] Jun 26 23:57:57 AtomNas smbd[25487]: #14 /usr/lib64/libtevent.so.0(+0xea7b) [0x14ae453b6a7b] Jun 26 23:57:57 AtomNas smbd[25487]: #15 /usr/lib64/libtevent.so.0(+0xcd77) [0x14ae453b4d77] Jun 26 23:57:57 AtomNas smbd[25487]: #16 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x14ae453afb61] Jun 26 23:57:57 AtomNas smbd[25487]: #17 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x14ae453afe3b] Jun 26 23:57:57 AtomNas smbd[25487]: #18 /usr/lib64/libtevent.so.0(+0xcd17) [0x14ae453b4d17] Jun 26 23:57:57 AtomNas smbd[25487]: #19 /usr/lib64/libsmbd-base-samba4.so(smbd_process+0x817) [0x14ae45824ce7] Jun 26 23:57:57 AtomNas smbd[25487]: #20 /usr/sbin/smbd(+0xb090) [0x564a47953090] Jun 26 23:57:57 AtomNas smbd[25487]: #21 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x14ae453b0791] Jun 26 23:57:57 AtomNas smbd[25487]: #22 /usr/lib64/libtevent.so.0(+0xec87) [0x14ae453b6c87] Jun 26 23:57:57 AtomNas smbd[25487]: #23 /usr/lib64/libtevent.so.0(+0xcd77) [0x14ae453b4d77] Jun 26 23:57:57 AtomNas smbd[25487]: #24 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x14ae453afb61] Jun 26 23:57:57 AtomNas smbd[25487]: #25 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x14ae453afe3b] Jun 26 23:57:57 AtomNas smbd[25487]: #26 /usr/lib64/libtevent.so.0(+0xcd17) [0x14ae453b4d17] Jun 26 23:57:57 AtomNas smbd[25487]: #27 /usr/sbin/smbd(main+0x1489) [0x564a47950259] Jun 26 23:57:57 AtomNas smbd[25487]: #28 /lib64/libc.so.6(+0x23177) [0x14ae451bb177] Jun 26 23:57:57 AtomNas smbd[25487]: #29 /lib64/libc.so.6(__libc_start_main+0x85) [0x14ae451bb235] Jun 26 23:57:57 AtomNas smbd[25487]: #30 /usr/sbin/smbd(_start+0x21) [0x564a47950b31] Jun 26 23:57:57 AtomNas smbd[25487]: [2023/06/26 23:57:57.459760, 0] ../../source3/lib/dumpcore.c:315(dump_core) Jun 26 23:57:57 AtomNas smbd[25487]: dumping core in /var/log/samba/cores/smbd Jun 26 23:57:57 AtomNas smbd[25487]: But there is nothing in /var/log/samba/cores/smbd.

I copied 10 files from another SMB shared directory to Unraid's shared directory and used them for a long time, such as using them as raw materials for video editing. Before the Mover process trigger, I could access and read these files without any issues. However, after the Mover process finished, I started experiencing errors while trying to read these files, which caused errors in the software I was using. But when I checked the MD5 checksum of these files, the 10 files in Unraid's shared directory were identical to the same 10 files in the other SMB shared directory. To fix the issue, I copied the 10 files again from the other SMB shared directory to Unraid's shared directory, and after that, the file reading worked fine again, and I could use my software without any problems. The issues mentioned above don't occur every time or with every file. They happen with a relatively low probability. I found that if I copy these 10 files from another SMB shared directory to Unraid's shared directory and immediately perform the Move operation, the problem doesn't occur when I use my software to read these files from Unraid's shared directory for an extended period of time.

Good question! I'd love to stay updated on here.

Thank you, I will check more about the Windows end logs. How about the Windows end open and write this file within Unraid moving this file. What happen in this situation?

Thank you.

I found something wrong with the file writing within Moving. I mentioned in this thread.

I'm running with 6.11.5 and as the screenshot shows. I can't find about the cancel or disable option.

I have a situation like this: There is a Windows machine in the network, connected to Unraid via SMB. This Windows device is slowly writing a file (the writing process lasts about 1 day and the file size is about 2GB). In the process of writing this file, Unraid starts Mover. During the Move process, the Windows device on the network prompts that the write failed (probably timed out). Unraid's Log found a record about the file that failed to write: move: skip: ***. Another thing that puzzles me is The move skip time displayed in Unraid's Log is Jun 1 17:30:47, while the Windows device's Log shows that the time of file writing failure is [10:01:42] of the next day. From a long-term observation, if the Windows device does not overlap with the time of Unraid Move from the creation of the file to the completion of writing, then there has never been a write failure.

It is running for 26days seen last reboot. And filled 29% of the Logs.

My unRaid running for weeks, and the log running higher. System may occur something wrong after the Log reach 99%. I want to know where holding the Log and how can I clear it.

Maybe it fixed. Thank you so much.

May 5 13:33:31 ***Nas emhttpd: error: get_key_info, 585: Invalid argument (22): get_message: /boot/config/BTRS.key (-3) In the log window, a large number of the above logs appear. And a line of such logs appears every second. Excuse me, what is the reason for this? What impact and consequences will this have?

Thank you. I run scrub all of disks without error.

Yes, I think so. One day there was an unexpected power failure, and the system was still running normally after restarting. However, after the next scheduled parity check, some errors ware indicated in the log. PS: My data drivers running with BTRS file system. You said "running a check on a drive will cause any corrupt files to be listed in the syslog". Do you mean running the SCRUB check in each data driver?