dlandon

Your remote share mounted in UD is dropping off-line. This is most likely a networking issue. If you are using Jumbo frames, change to the default MTU.

Do you have any settings on the Mac related to SAMBA? Take a look at this: https://support.apple.com/en-us/HT204445

It takes 21 seconds to mount a btrfs file system? And 40 seconds to umount? Seems a bit long to me.

Daily.

I've extended the mount and umount timeouts to 30 and 45 seconds respectively in the latest release. You should do a file system check on that disk though. I'm not sure if this log entry is an issue or not. Could you post the complete diagnostics?

Looks like more time out adjustments are needed.

No. The credentials are set when the device is first mounted. If they are incorrect, the CIFS mount should fail. I have an idea here. I don't know how the Mac implements SMB. Is it possible that you have the credentials set wrong and the Mac share mounts regardless and then fails when the share is accessed? Remove the remote share from UD and then set it up again. Be sure the credentials are set correctly. I thought the latest SAMBA only had security fixes, but it's possible other changes were made. SMB2 is not a new protocol.

Sometimes the command line works when the gui doesn't. In a terminal session enter 'diangostics'. The diagnostics will be written to /flash/logs/ The disk has issues, but looks to be more of a cable/controller issue. SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) This shows the disk can do 6.0 Gb/s, but is only running at 3.0 Gb/s. If the controller is capable of 6.0 Gb/s, then the higher speed should be used. This might also indicate a cable problem. I'm not a disk expert, but I don't think the Seagate disk is failing.

There is not a lot of information on this error, but what I did find is that the error occurs when the remote device is written to. If your Dockers are writing to the remove mount, then that's when you'd see the errors. It was suggested that the permissions on the remote source (your Mac) might have to be changed. I don't know what needs changing. I'm sure this started on 6.8 because there is a new version of SAMBA.

This error is from SAMBA. Start by un-mounting the remote share and see if the errors stop. If they do then we know where the error is coming from. I would suggest you check your credentials and be sure not to have special characters kn the password if you can avoid it. Stick with alpha and numeric.

I guess UD just had a moment.

I don't see anything in the log. Re-install UD from CA and get a screen shot of any errors.

This is from the remote mount you have in UD. CIFS is the network protocol used to connect to the remote mount. I suspect it may be from your remote mount having credentials. Post this in the UD forum for further help.

Post diagnostics. Yes, you can re-install UD from CA.

Post diagnostics. Yes, you can re-install UD from CA.

I'm not sure what is causing your high cpu usage, but you are remote mounting shares and when the remote server goes off-line, there are disk commands that will take longer and possibly time out. In your log: Dec 9 23:00:59 AnimNAS preclear_disk_4A4548303948504E[22584]: smartctl exec_time: 3s Dec 9 23:01:10 AnimNAS preclear_disk_4A454B543957555A[28410]: smartctl exec_time: 3s Dec 9 23:01:29 AnimNAS preclear_disk_4A4548303948504E[22584]: smartctl exec_time: 8s Dec 9 23:01:40 AnimNAS preclear_disk_4A4548303948504E[22584]: smartctl exec_time: 19s Dec 9 23:01:50 AnimNAS preclear_disk_4A4548303948504E[22584]: smartctl exec_time: 29s Dec 9 23:02:00 AnimNAS preclear_disk_4A454B543957555A[28410]: smartctl exec_time: 9s Dec 9 23:02:10 AnimNAS preclear_disk_4A4548303948504E[22584]: smartctl exec_time: 1s Dec 9 23:02:11 AnimNAS preclear_disk_4A454B543957555A[28410]: smartctl exec_time: 20s Dec 9 23:02:21 AnimNAS preclear_disk_4A454B543957555A[28410]: smartctl exec_time: 30s Dec 9 23:02:32 AnimNAS preclear_disk_4A454B544233585A[2893]: smartctl exec_time: 10s Dec 9 23:02:42 AnimNAS preclear_disk_4A454B544233585A[2893]: smartctl exec_time: 20s Dec 9 23:02:52 AnimNAS preclear_disk_4A454B544233585A[2893]: smartctl exec_time: 30s Dec 9 23:02:59 AnimNAS preclear_disk_4A454B55324D5A5A[17666]: smartctl exec_time: 6s Dec 9 23:03:09 AnimNAS preclear_disk_4A454B55324D5A5A[17666]: smartctl exec_time: 16s Dec 9 23:03:19 AnimNAS preclear_disk_4A454B55324D5A5A[17666]: smartctl exec_time: 26s I think your expectation of what your Unraid server can/will do is too high. Mounting UD disks, remote shares, and preclearing 4 disks at once is a bit much. If you insist on preclearing disks (I'm one of those that believes it is not necessary and a waste of time), do it on another machine or stop mounting UD disks and remote shares until the preclears are done.

Fixed in latest update.

The docker has been updated.

Change to: hook_script = '/usr/bin/zm_detect_wrapper.sh'

That's not consistent with how other things work in Unraid. This operates the same as the syslog.

Post your diagnostics.

The file system on the disk is not recognized by UD.

Reiserfs is a deprecated file system and I don't think it supports SSDs like the more modern file systems. You should probably consider moving to XFS or BTRFS.

I made a change to add discard to disk mounts. Because it's an SSD, UD added the discard. Obviously reiserfs doesn't support the discard. I can fix that. I guess this begs the question of why use reiserfs on an SSD in the first place? Wouldn't XFS or BTRFS be a better choice?

Is the disk an ssd?