dlandon

The 'mount' button is a manually initiated disk mount. The 'auto mount' button tells UD to mount the disk when the array starts - either on reboot or when the array is stopped and then restarted. Looks like you did as I suggested and used a native Unraid format. Before you used ext4. Based on your feedback, I'm thinking that either UD did not format the disk properly, or Linux lunched the disk on reboot. I doubt it. The difference this time is the file system you used. That's why I suggested using wither xfs or btrfs. Unraid does not use ext4, it just happens to be built into Linux. Using xfs or btrfs allows you to incorporate the disk into Unraid because of the supported file system. Using UD to mount VMs, Dockers, etc is not really what it was originally designed for. Doing what you are doing here was a natural progression of a feature that UD was able to support in the short term. LT plans to move this ability to Unraid natively by supporting multiple disks outside the array so separate disks can be used for VMs, Dockers, etc and be managed and supported by Unraid. For example disk monitoring and disk encryption. Currently Unraid supports this only in a single cache disk.

Yes.

I would suggest formatting the disk in a file system native to Unraid - xfs or btrfs. There may be an issue with ext4 support.

Did it really time out or fail for some other reason?

I have updated UD and added an indicator that a drive script is running. You'll see the 'Unmount' button show 'Running...' when the drive script is running. If you don't unmount the device in your script when your script is done, add this line to the end of the 'ADD' case: # This will refresh the UD webpage when the script is finished. /usr/local/sbin/rc.unassigned refresh $DEVICE This will refresh the UD webGUI and turn off the 'Running...' indicator when the script is finished. This indicator is so you can tell the script is running so you don't try an unmount, which fails because the device is busy.

Once you get everything settled, let's see if the mounts still time out.

Doesn't the Synology support SMB2 or SMB3? You are forcing all SMB mounts to SMB1. You should turn forcing SMB1 off if you can. SMB1 is not as secure as SMB2 and SMB3. I can extend the timeout for SMB1 mount, but I have spent a lot of time working on the perception that UD hangs when things take a long time and I'm not fond of extending time outs and getting hammered again for "hangs". I'm thinking this is a situation with your system.

Ok. A SMB remote mount should not take that long. It should be very quick. Now to understand why it takes so long. When did this start? What changed? Does your remote server have to spin up disks?

When you manually mount the SMB share, how long does it take? More than 10 seconds?

Remove the plugin, then remove the /flash/config/plugins/unassigned.devices/ folder.

The passwords for SMB mounts are now encrypted and unless you recreate the SMB mount after updating UD, it will fail to mount. Did you delete the SMB mount and re-create it?

There are people here that are a lot better than I am at dealing with disk issues. @johnnie.black could possibly lend a hand.

That disk has some issues: Jan 26 10:53:16 Tower unassigned.devices: Adding disk '/dev/sdu1'... Jan 26 10:53:16 Tower unassigned.devices: Mount drive command: /sbin/mount -t vfat -o rw,auto,async,noatime,nodiratime,nodev,nosuid,umask=000 '/dev/sdu1' '/mnt/disks/stagingserver' Jan 26 10:53:16 Tower kernel: FAT-fs (sdu1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. Jan 26 10:53:16 Tower unassigned.devices: Successfully mounted '/dev/sdu1' on '/mnt/disks/stagingserver'. Jan 26 10:53:16 Tower unassigned.devices: Adding disk '/dev/sdu2'... Jan 26 10:53:16 Tower unassigned.devices: Mount drive command: /sbin/mount -t ext4 -o rw,auto,noatime,nodiratime,async,nodev,nosuid '/dev/sdu2' '/mnt/disks/staging' Jan 26 10:53:16 Tower kernel: EXT4-fs (sdu2): warning: mounting unchecked fs, running e2fsck is recommended Jan 26 10:53:16 Tower kernel: EXT4-fs (sdu2): mounted filesystem without journal. Opts: (null) Jan 26 10:53:16 Tower unassigned.devices: Successfully mounted '/dev/sdu2' on '/mnt/disks/staging'. Unmount the disk. Then click on the '+' sign by the partition and then click the four squares and do a correcting disk check.

Whenever you post an issue, post diagnostics. Not posting diagnostics slows down a response to your issue because I have to ask for diagnostics.

Post diagnostics. SMB is working fine.

If you nave updated the ownCloud Docker and get a message about php 7.3, you are running an older version of ownCloud that is not compatible with php 7.3. ownCloud 10.3 is compatible with php 7.3 and I have updated the Docker to support ownCloud 10.3 with php 7.3. In order to get around the php error and update ownCloud, there is a legacy Docker you can use that uses php 7.1 so you can update ownCloud. Edit your docker template and change the repository to: dlandon/owncloud-legacy This will load a version of the docker with php 7.1. Perform your update and then change the repository back to: dlandon/owncloud The legacy Docker will not be supported, so be sure to go back to the published Docker.

If it was native in Unraid, you wouldn't be able to take advantage of it based on your signature.

Log messages: Jan 23 00:43:05 MovieRaidServer unassigned.devices: Error: shell_exec(/bin/df '/mnt/disks/192.168.2.5_downloads' --output=size,used,avail | /bin/grep -v '1K-blocks' > /tmp/unassigned.devices/df 2>/dev/null) took longer than 2s! Jan 23 00:43:07 MovieRaidServer kernel: CIFS VFS: Cancelling wait for mid 28622620 cmd: 5 Jan 23 00:43:07 MovieRaidServer kernel: CIFS VFS: Cancelling wait for mid 28622621 cmd: 16 Doing a little research seems to indicate an opportunistic locking issue on the remote share.

The disk is not being mounted with discard by UD: Jan 22 06:37:03 Unraid unassigned.devices: Adding disk '/dev/sda1'... Jan 22 06:37:03 Unraid unassigned.devices: Mount drive command: /sbin/mount -t xfs -o rw,noatime,nodiratime '/dev/sda1' '/mnt/disks/Seeding' You have the Dynamix SSD Trim plugin installed and set to trim every hour. That plugin is initiating the fstrim. The fstrim is run on all SSD devices. Apparently fstrim thinks the drive is an SSD. You can ignore the message. It is harmless. Once an hour is too often tho run fstrim. Once a day is sufficient.

Your best bet for help is at the Zoneminder forums.

Post diagnostics.

You only need to remove the smb mounts and re-add if they fail on permission denied. You have several issues that may be related to the drop outs.: Jan 21 10:46:00 MovieRaidServer root: Fix Common Problems Version 2019.12.29 Jan 21 10:46:00 MovieRaidServer root: Fix Common Problems: Warning: Docker Application jellyfin has an update available for it Jan 21 10:46:00 MovieRaidServer root: Fix Common Problems: Error: Docker application jellyfin has volumes being passed that are mounted by Unassigned Devices, but they are not mounted with the slave option Jan 21 10:46:00 MovieRaidServer root: Fix Common Problems: Error: Docker application plex has volumes being passed that are mounted by Unassigned Devices, but they are not mounted with the slave option ### [PREVIOUS LINE REPEATED 2 TIMES] ### Jan 21 10:46:07 MovieRaidServer root: Fix Common Problems: Warning: Unassigned Devices Plus not installed ** Ignored Jan 21 10:46:34 MovieRaidServer kernel: SMB2_read: 12 callbacks suppressed Jan 21 10:46:34 MovieRaidServer kernel: CIFS VFS: Send error in read = -4 ### [PREVIOUS LINE REPEATED 9 TIMES] ### Go to Fix Common Problems and fix the Docker issues.

Post diagnostics.

It took me multiple tries to get it right. The latest version is finally working properly.

Yes, you can enter any of the fields manually. Unfortunately with all the Samba changes regarding phasing out NetBIOS, the SMB server lookup is not working. UD uses a bit of a hack to come up with the servers it can, but it depends on NetBIOS.