Had to downgrade now two time to 6.93 because of hanging system while accessing samba share.
1 time with Android Filetransfer
1 time with Windows 10 Filetransfer
under 6.9.3 i can do it for hours. With 6.9.4 it starts hanging within minutes. No Reboot possible (Web, Button and ssh not working)- I have to Hard Reset
Error Feedback in Android: Transport1 timedout waiting for response to smbComCreatDirectory[command=SMB_COM_CREAT_DIRECTORY, received=false,errorCode=0,flags0x0018,flags2=0C803, signSeq=0,tid20837mpid8553mid=3616,mid=4362,wordCount=0,byteCount=17,directoryName="Foldername"
Sorry don't go again on 6.9.4 - it was costing me now 90+ Minutes of work. 6.9.3 is running stable for weeks.
Fix it!
Model: RN10400|ReadyNAS 100 Series 4- Bay (Diskless)
I've seen several Samba hangs with 6.9.4 in my RN526x as well. I'm still trying to figure it out. Strict sync was set, but changing that didn't help. Resetting permissions didn't help either.
However my issue seems to be different. The web UI and ssh both still work after the hang.
Not sure if it is releated, can you try to open ssh access and do 'echo "use sendfile = 0" > /etc/frontview/samba/smb.conf.overrides' , then 'systemctl restart smb' or reboot your box to see if that helps ?
Not sure if it is releated, can you try to open ssh access and do 'echo "use sendfile = 0" > /etc/frontview/samba/smb.conf.overrides' , then 'systemctl restart smb' or reboot your box to see if that helps ?
I tried this and it didn't help. I was able to reproduce the hang. I rebooted the NAS and see this in kernel.log:
Sep 30 05:37:46 NAS kernel: INFO: task smbd:11847 blocked for more than 200 seconds.
Sep 30 05:37:46 NAS kernel: Tainted: P O 4.4.140.x86_64.1 #1
Sep 30 05:37:46 NAS kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 30 05:37:46 NAS kernel: smbd D ffff880168ed3d30 0 11847 1 0x00000004
Sep 30 05:37:46 NAS kernel: ffff880168ed3d30 ffff88017ab9d240 ffff880134dcb8a0 ffff88017ab9d240
Sep 30 05:37:46 NAS kernel: ffff880134dcb8a4 00000000ffffffff ffff880134dcb8a8 ffff880168ed3d40
Sep 30 05:37:46 NAS kernel: ffffffff888e2ab0 ffff880168ed3d50 ffffffff888e2c93 ffff880168ed3db0
Sep 30 05:37:46 NAS kernel: Call Trace:
Sep 30 05:37:46 NAS kernel: [<ffffffff888e2ab0>] schedule+0x69/0x7f
Sep 30 05:37:46 NAS kernel: [<ffffffff888e2c93>] schedule_preempt_disabled+0x9/0xb
Sep 30 05:37:46 NAS kernel: [<ffffffff888e3b75>] __mutex_lock_slowpath+0x98/0xf1
Sep 30 05:37:46 NAS kernel: [<ffffffff888e3be0>] mutex_lock+0x12/0x22
Sep 30 05:37:46 NAS kernel: [<ffffffff888e3be0>] ? mutex_lock+0x12/0x22
Sep 30 05:37:46 NAS kernel: [<ffffffff882aeb9d>] btrfs_file_write_iter+0x6b/0x3c6
Sep 30 05:37:46 NAS kernel: [<ffffffff880add97>] ? do_futex+0xdb/0x86e
Sep 30 05:37:46 NAS kernel: [<ffffffff8811c9bd>] __vfs_write+0x9a/0xc3
Sep 30 05:37:46 NAS kernel: [<ffffffff8811d0ce>] vfs_write+0xb6/0x160
Sep 30 05:37:46 NAS kernel: [<ffffffff8811dc09>] SyS_pwrite64+0x5c/0x7b
Sep 30 05:37:46 NAS kernel: [<ffffffff888e540a>] entry_SYSCALL_64_fastpath+0x1e/0x8e
thank you for the efford. I added the samba fix and I am waiting, what is happening. As soon as I get a hang up i will send the logs. I deleted them because it was 3000 pages of logs, which i considered is not necessary (While my 90 Minutes work) - So keep on - But I am lucky that the error could be reproduced.
Oct 04 19:44:49 nas-bruce kernel: INFO: task smbd:19030 blocked for more than 200 seconds.
Oct 04 19:44:49 nas-bruce kernel: Tainted: P O 4.4.140.armada.1 #1
Oct 04 19:44:49 nas-bruce kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 04 19:44:49 nas-bruce kernel: smbd D c068129c 0 19030 2894 0x00000001
Oct 04 19:44:49 nas-bruce kernel: [<c068129c>] (__schedule) from [<c068155c>] (schedule+0xa4/0xd4)
Oct 04 19:44:49 nas-bruce kernel: [<c068155c>] (schedule) from [<c0681860>] (schedule_preempt_disabled+0x24/0x40)
Oct 04 19:44:49 nas-bruce kernel: [<c0681860>] (schedule_preempt_disabled) from [<c0683a1c>] (__mutex_lock_slowpath+0x1b4/0x374)
Oct 04 19:44:49 nas-bruce kernel: [<c0683a1c>] (__mutex_lock_slowpath) from [<c0683c00>] (mutex_lock+0x24/0x40)
Oct 04 19:44:49 nas-bruce kernel: [<c0683c00>] (mutex_lock) from [<c02a10cc>] (btrfs_file_write_iter+0x5c/0x524)
Oct 04 19:44:49 nas-bruce kernel: [<c02a10cc>] (btrfs_file_write_iter) from [<c00d366c>] (__vfs_write+0xa8/0xd0)
Oct 04 19:44:49 nas-bruce kernel: [<c00d366c>] (__vfs_write) from [<c00d3cdc>] (vfs_write+0xa8/0x130)
Oct 04 19:44:49 nas-bruce kernel: [<c00d3cdc>] (vfs_write) from [<c00d44ac>] (SyS_pwrite64+0x5c/0x7c)
Oct 04 19:44:49 nas-bruce kernel: [<c00d44ac>] (SyS_pwrite64) from [<c000eb20>] (ret_fast_syscall+0x0/0x40)
The second one may be the real issue. we are trying to reproduce it.
Guys, any special operation need to be done ? Or just drag and drop files to a samba share?
Guys, any special operation need to be done ? Or just drag and drop files to a samba share?
In my case, the failure always happens (every time) when I drag/drop a file from one share to another from Windows 10. Note the entire data volume is mapped to a drive letter. Generally I am doing this between two specific (public) shares. Windows explorer completely locks up from that PC. If I do net use * /delete and remap the drive, I can regain access, but the file I was copying remains locked on the destination share.
The strict sync setting doesn't matter, and neither share has auto defrag enabled. I haven't seen it when I copy files between the same shares with SSH. But once the problem happens with SMB, the destination file can't be deleted or moved with SSH either. When I compare the locked destination file with the source, they do not match. Once the problem occurs, I end up rebooting the NAS fo recover.
I haven't had the time to narrow it further (whether it happens between other shares, or whether I can reproduce it on an RN524, RN102, or RN202). I believe the problem also will occur if I copy the file from the mapped data volume to a different mapped drive (mapping only the target share). But I'm not 100% certain of that.
The workaround for now is to copy the file from the source share to the PC hard drive, and then copy it again from the hard drive to the target share. That never fails. Copying files within the source share, or within the target share also never fails. So both shares can be read/written from the PC, the problem only happens when I drag/drop something directly from the source to the target share.
Thanks for trying that. As StephenB said he can only saw this issue by copying files between shares, may I know what's your way to reproduce this constantly?
i reproduce the bug by using the NAS. 😉 No for real - NAS hang 20-60 Minutes after updating everytime. First 24 hours made. 72 hours following. "Device Uptime: 1 day 2 hours 12 minutes"
I have incremential backups - sometimes 160 GB big running every day here plus "normal" NAS traffic.
And it always hanged when something downloaded to the public share / user folders .
Something was copied / backuped from Android to the NAS .
So i guess the rebuild is working like 6.9.3 only with the updates.
BUT - i have another Problem so far with the rebiuld - I just checked the logs and it did not recognize the files system of the USB 3 attached Backup HDD 😞 - Gotta check on that now .
If I copy any file from share to share with Windows 10, the copy instantly locks up and fails. Any attempt to use the destination file results in the process locking up in state "D" according to `ps` output. Including attempting to `rm` the file. This also includes any processes that scan the files such as Plex, resulting in Plex locking up requiring restarting the NAS. Even restarting the NAS fails and requries a hard-reset.
Once the device has reset, I am able to rm the offending files through SSH and everything seems fine again.
Copying the files down to the local PC and back to the other share, or even copying from share to share via SSH works fine.
I've only encountered this issue since 6.9.4. Very much looking forward to a fix...
I am fine in 6.9.3 but when I try to upgrade to 6.9.4 the webpage times out and just sits there. The connection to the Administrator Webpage fails. I let it sit for an hour but nothing happens. When I reboot it comes back up but on Firmware 6.9.3 and asks me again if I want to do an upgrade to 6.9.4. It was also crashing on loading the Administrator Webpage.
I ran a scub on the disks and today it did the same thing but at least now the Webpage does not crash, I just cant upgrae to 6.9.4 on completing the downloading and install the Administrator webpage hangs and disconnects. The only way to fix it is to reboot the NAS but then it comes back up on version 6.9.3. I am curious if anyone else if having problems upgrading to 6.9.4. I think I will just wait for the next firmware update.
