dlandon

Probably all of the above.

That's a bug I introduced by accident yesterday. I'll have a fix later today.

Post diagnostics.

If Linux can't see a partition and file system on the disk, UD can't do anything with it. Maybe some of the disk gurus here can suggest a method of fixing the disk partition and file system.

It's better to create the share and specify the IP address instead of the server name if you have those issues.

I just remembered there is a trick that should fix this for you without a reboot, Just add the share as if you were setting it up for the first time and it will update and 'fix' the configuration.

Be sure to turn off auto mount before a reboot or you'll end up back in the same situation.

Fixed in the next release. You will have to remove the remote share and add it back. It will be fixed when the remote share is added back.

Here is what I see in your samba_mounts.cfg file: [//ALSBATH/internal] protocol = "SMB" ip = "192.168.1.45" The 'ip' value is supposed to be 'ALSBATH', and not an IP address. and [//ALSSLEEP/internal] protocol = "SMB" ip = "192.168.1.25" The 'ip' is supposed to be 'ALSSLEEP', and not an IP address. I'm not sure how you got into this situation. UD should never let this happen. I suspect these are both old configurations and UD did something different then. Do the following: Stop your server. Remove the two SMB mounts. Start your server. Add the two shares back and mount them to see if it's all sorted out.

Can you PM me the '/flash/config/plugins/unassigned.devices/samba_mount.cfg' file? Please turn off the UD logging. It is too hard to read the log with the UD messages flooding the log.

Can you PM me the '/flash/config/plugins/unassigned.devices/samba_mount.cfg' file?

Post your diagnostics.

The best way to create a device script is to click on the 'Default' button to load the default script. Then put your custom operations in the proper place in the default script to do what you want. The UD scripts are stored on the flash at /flash/config/plugins/unassigned.devices/. It's not a good idea to use a User Script as a device script. The best use of a User Script is to do something like the following, but run it as a User Script: Mount the UD disk using the rc.unassigned script and refer to the disk's alias name rather than a device designation as they change on reboot. Perform the desired operations. Unmount the disk using the rc.unassigned script, again referring to the disk by it's alias name and not device designation. I have a backup script to a UD device run in User Scripts once a day. Click on the 'Help' icon while on the UD webpage and you'll see more about the rc.unassigned options.

It looks like your 'data' is mapped incorrectly. Your 'data' directory is supposed to be mapped to '/config/': root@7619b6d5b2c3:/config# ls -la total 12 drwxrwxrwx 8 abc users 99 Jun 5 09:12 . drwxr-xr-x 1 root root 226 Apr 28 12:46 .. -rwxrwx--- 1 abc users 3753 Aug 11 2018 custom.cnf drwxrwx--- 11 abc users 4096 Jul 27 16:55 data drwxrwxrwx 5 abc users 4096 Aug 4 08:43 database drw-rw---- 2 abc users 38 Apr 13 07:26 keys drwxrwxrwx 4 abc users 32 Aug 11 2018 log drwxrwx--- 3 abc users 64 Aug 4 08:43 nginx drwxrwxrwx 3 abc users 22 Aug 6 08:42 www This is probably because you didn't set the data directory when you set up ownCloud to '/data' as mentioned in the original post.

Update UD, unmount and remount your remote shares and see if it makes any difference. Don't enterprise disks draw more power? And you're concerned over power draw of a NIC?

Use Settings->SMB->SMB Extras to make your changes to the file. This will apply the settings after you have made changes. Don't edit the file directly.

I asked because your log does not show any UD mounts to either NFS or CIFS remote shares. Several observations. You have some parity errors: Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=288 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=296 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=304 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=312 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=320 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=328 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=336 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=344 AuAug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=280 g 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=352 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=360 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=368 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=376 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=384 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=392 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=400 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=408 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=416 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=424 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=432 Aug 1 03:00:15 unraid kernel: md: recovery thread: P incorrect, sector=440 You have some Fix Common Problems issues: Jul 29 20:44:06 unraid root: Fix Common Problems: Warning: Write Cache is disabled on disk2 Jul 29 20:44:06 unraid root: Fix Common Problems: Warning: Write Cache is disabled on disk3 Jul 29 20:44:06 unraid root: Fix Common Problems: Warning: Write Cache is disabled on disk5 You are using a realtek NIC. The drivers for Realtek NICs ar notorious for having issues with Linux because they are not well maintained. My suggestions: Set the NFS version in UD Settings to NFSv4 so you don't have to edit the '/etc/nfsount.conf' file after each reboot. Fix the FCP issues. Fix the parity errors. Change NICs. Intel NICs work very well in Unraid. You said you were using NFS mounts. In the next release of UD, I've made some adjustments in NFS mounts that may help. Most notable the 'noatime', and 'nodiratime' that won't do disk writes on every file access.

So you are using UD to mount a remote NFS share, then you use a file manager on the local machine to copy from /mnt/remotes/... to desired destination on the local machine? What is the remote server? Another Unraid server? What file manager are you using?

I just ran a test: Mount a UD device. Delete some files through the UD device share. Empty UD share trash - success. Delete some files through the UD device share. Empty All Trash - success. Let me know if you are doing something different than what I've done here and I'll see if I can reproduce your issue.

There are several ways to execute the script. Plug in a disk and if the auto mount switch is set, the device will mount on it's own. The other way is to click the lightning bolt icon when the disk is mountd and your script wil be run. The UD log is only what is logged by your script. Look at the syslog and UD will log actions when you install your disk.

That controls what version is used as the starting point for auto negotiation of a client. I need some information on your setup. I assume you are mounting NFS shares remotely and transferring files over the LAN. How are you mounting the NFS shares? Fstab or UD?

Automount is set per drive. Set it on for the drives you want to auto mount, off if you don't want it to auto mount.

Turn on the auto mount switch. You have sharig turned on, but you haven't set up the sharing modes in UD Settings.

How did you change from NFSv3 to NFSv4 in Unraid? Post diagnostics.

No, but you can create the btrfs pool in Unraid, then unassign it and UD can mount it.