dlandon

The manual procedure to update is not difficult, but a bit tedious. The update through the ui is being deprecated, so the manual method is the only way. There have been some changes to the update procedure that preserve apps so you don't have to go to the marketplace and load them all from scratch. ownCloud has deprecated the support for php 7.0 and recommends php 7.3. They also recommend Ubuntu 18.04LTS. The next revision of the docker will upgrade to Ubuntu 18.04LTS. This will be a seamless update and you won't have any issues like this. There was also a change related to the cron task.

Sorry, this refers to not spinning them up. UD always applies a spin down timer of about 30 minutes. There is no way to turn that off. Disk activity should keep it spun up. If you have the cache_dirs plugin installed, be sure that it is not caching your UD disk so disk activity will keep it spun up.

I've mounted remote NFS shares and not had any issues. While I understand your frustration about this issue, NFS seems to be working fine. It is probably related to your particular setup. If it's that big a problem, roll back to 6.7.

Read this about not having UD spin down drives: This will keep UD from applying a drive spin down timer. The drive may be spinning itself down though.

Turn off mover logging. Should solve the problem.

I updated the docker today to update to php 7.3 and address some issues like cron not working. I also made some minor configuration changes. I have ownCloud working on Phusion 0.11 (Ubuntu 18.04). I will do some more testing over the next few days and then release it.

You can't have Jumbo frames anywhere on your network. They might have worked in the past, but things change in Linux. Remote mounts depend on a solid reliable network connection, No one else has reported this problem yet.

Jumbo frames have shown to be an issue, Set the MTUs to defaults. Don't use Jumbo frames until you have things working. Then try Jumbo frames. You should post this as an issue with your setup and not a 6.8 bug. It's not a NFS issue, it's a network issue

I didn't see any remote shares mounted with UD. You do realize UD can mount the remote NFS shares? I guess my concern is DIY mount options. Let UD do it. I've not seen any issues like you describe with remote NFS mounted shares. Are you using Jumbo frames?

It looks like you have several issues. Disk sdf has a cable or interface problem: 7 Seek_Error_Rate POSR-- 073 060 030 - 73416400066 Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2551 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2551 CDB: opcode=0x88 88 00 00 00 00 00 7d 80 09 00 00 00 00 08 00 00 Dec 31 08:00:10 Odin kernel: print_req_error: I/O error, dev sdf, sector 2105542912 Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2552 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2552 Sense Key : 0x2 [current] Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2552 ASC=0x4 ASCQ=0x2 Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2552 CDB: opcode=0x88 88 00 00 00 00 00 7d 80 09 08 00 00 00 08 00 00 Dec 31 08:00:10 Odin kernel: print_req_error: I/O error, dev sdf, sector 2105542920 Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2553 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2553 Sense Key : 0x2 [current] Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2553 ASC=0x4 ASCQ=0x2 Dec 31 08:00:10 Odin kernel: sd 10:0:0:0: [sdf] tag#2553 CDB: opcode=0x88 88 00 00 00 00 00 7d 80 09 10 00 00 00 08 00 00 Dec 31 08:00:10 Odin kernel: print_req_error: I/O error, dev sdf, sector 2105542928 Your remote nfs share has something going on, but I don't know what: Dec 31 16:29:19 Odin rpcbind[17421]: connect from 192.168.0.60 to null() Dec 31 16:29:19 Odin rpcbind[17422]: connect from 192.168.0.60 to getport/addr(nfs) Dec 31 16:29:19 Odin rpcbind[17423]: connect from 192.168.0.60 to null() Dec 31 16:29:19 Odin rpcbind[17424]: connect from 192.168.0.60 to getport/addr(nfs) Dec 31 16:29:20 Odin rpcbind[17484]: connect from 192.168.0.60 to null() Why don't you use UD to mount your remote NFS shares?

I am updating the docker to php 7.3. You should update onCloud before updating the docker. ownCloud 10.3 is compatible with php 7.3. Earlier versions may have some issues.

UD+ shouldn't affect the ntfs disk at all. Try removing UD+ and see if it changes anything. Please post diagnostics.

Install UD then install UD+ for the additional features it provides.

I've updated the Docker to Phusion 0.11 (Ubuntu 18.04). One of the changes is you'll have to change PATH_FFMPEG to /usr/bin/ffmpeg. Avconf has been removed.

Install UD+ and format the drives as necessary. The feature has not been removed, it's just optional. I never format drives on my main server.

No problem. I clarified on the first post of UD.

Dang, pass the buck back. I got it.

Looks good. Couple clarifications. The exFAT is only for mounting large flash drives; I believe larger than 64GB. Unraid natively supports FAT. UD+ is also necessary for 'Destructive Mode' to work.

See if my clarifications in the first post are better.

I'm don't think that will happen. Now that cache pooling is planned for 6.9, this reduces UD's functionality to backup and temporary storage mounts and remote mounts. The desire to include UD into Unraid mostly came from UD doing array operations - i.e. VM and Docker storage. With cache pooling, this is much less an issue. I think LT has enough on their plate without having to deal with the remote mounts mess.

Yes. I can see people getting confused when they reboot after updating UD and don't have UD+ installed and wonder why certain things are now broken. I also sense a lot of confusion about UD Settings and that UD even has settings. I'll look into possibly adding a link on the UD page to the settings.

On the update of UD, the packages installed originally by UD will remain. When you reboot, they will not be re-installed. If you need the additional features offered by the UD+ plugin, then I recommend you install UD+ also and you will then see a seamless update after a reboot.

That's good news. The subtleties of the timings in shutting down Unraid can be confusing, especially when things take a bit of time to shutdown - like remote mounts. My goal in shutting down UD mounts is to be sure that all unmounts are as safe as possible so data will not be lost or corrupted. Sometimes this can be difficult because CIFS (remote mounts) is a pretty contrary beast. I also don't want things to hang or take too long.

No. UD Plus is just an add on plugin that installs the packages needed for the additional features. It is not an alternative to the base UD.

In the next release of UD, I am separating out all the packages loaded currently by UD into a separate plugin called 'Unassigned Devices Plus'. The packages removed from the base UD affect mounting of HFS+ and extFAT disks. If you need to mount these formats, install the UD plus Plugin. The other package not installed any more in the base UD s 'parted'. Parted is used for formatting and partition delete on disks. If you need to do any formatting or deleting of partitions, install the UD Plus plugin. All disk formats supported by Unraid are supported in the base UD plugin. The idea behind all this is the installation of packages into Unraid that are not used by the majority of users. I am not a fan of installing a lot of packages into Unraid, especially packages that are not being used. This also cuts down on the UD plugin installation time by not downloading and installing all those packages. The UD Settings page will indicate which features can not be enabled without the UD Plus plugin being installed. Check the 'Help' on that page for further information.