Leaderboard

No, but personally I would upgrade to 6.3.5 anyways. The leading period tells mover to not bother moving the share to array. The more common method however is to set the appdata share to be cache only or cache-prefer If the cache drive drops dead, the docker.img file is a joke to rebuild, and doesn't contain any "real" information or metadata With a non-redundant cache drive, what most people do is backup the appdata share to the array (weekly?) CA Appdata Backup/Restore does this for you on a schedule That particular directory is actually in RAM. And with plugins, the install pretty much has to be in ram. Docker, the install is within the docker.img file which tends to be stored on the cache drive. By enabling Disk Shares on unRaid. But, TBH you're going to have an easier time simply pointing the docker appdata location for each app to the existing share/folder you've already got. Simply moving stuff around (especially over the network) will be problematic due to permissions, symlinks, etc. Best bet is to point the default docker appdata location to be /mnt/cache/.appdata/libraries, and then on installation of the new apps, verify the appdata (/config) folder is pointing to the existing folders. Actually LT offers such a service, albeit for a fee. You can get details on their website. ---------- Other thoughts. If simply pointing the /config folders to the existing ones from the plugins doesn't work, then you're going to be better off starting the apps over from scratch. Less aggravation and headaches that way.

The drive serial number is listed in the error, and on the main GUI, and several other places in the GUI. If you've already downed the box, just look in the screenshot you posted a couple posts back.

Thanks John! Hope below might help ... /proc/mdcmd should give you what you need for array drives Here are the values for my RAID0 parity (I gave it the name "PARITY" via its config tool. The controller assigned that long serial number ending with 223): diskId.0=PARITY_0000001296206223 rdevName.0=sdb rdevSize.0=7814036428 GB calculation: 7814036428 * 1024 / 1000/1000/1000 = 8001.57 And here is an example for a regular disk: diskId.1=HGST_HDN728080ALE604_VLKK7xxx rdevName.1=sdv rdevSize.1=7814026532 GB calculation 7814026532 * 1024 / 1000/1000/1000 = 8001.56 "lsscsi -i" returns similar string, and also includes non-array disks. No size though. [1:0:0:0] disk Areca PARITY R001 /dev/sdb PARITY_0000001296206223 [8:0:0:0] disk ATA HGST HDN728080AL W91X /dev/sdv SATA_HGST_HDN728080ALVLKK7xxx "fdisk -l /dev/sdX" returns size information: Here is the output for the parity disk: Disk /dev/sdb: 7.3 TiB, 8001573355520 bytes, 15628072960 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 445C476F-4F1C-4C22-9E38-5E13899A9987 Device Start End Sectors Size Type /dev/sdb1 64 15628072926 15628072863 7.3T Linux filesystem Hope this helps!

not really, i tend to go with the endpoints that have the most bandwidth (and of course port forwarding), the netherlands is one of the higher speed endpoints, but the choice is yours. connecting to a torrent swarm (that is a collection of seeds and leechers) without a incoming connection will put a strain on the swarm population, having to switch from the native tit-for-tat system for certain peers is not good and is normally frowned upon. no other changes required, the assignment of the incoming port is done for you.

It's up to you and it depends if you have backups or not, it would be safer.

Your data will be fine. Even if you start with a complete new installation, unRAID preserves your data. You need to know the current disk assignment including parity, because this needs to be re-entered. Shares are automatically created from the top folders in your array, but will have default settings which may need to be updated.

latest from wendel @level1techs regardin iommu GPU Passthrough for Virtualization with Ryzen: Now Working

To be honest, I have yet to see any store ever run diagnostics on hardware. If it passes BIOS tests, then its good to go for them. Try a different stick and a fresh install.

I use a Libresonic docker and Dsub app my android devices. I also setup Letsencrypt docker to reverse proxy so it's available outside my network. My wife uses the Dsub app all the time, working out, streaming to the car radio, casting to various speakers in the house.

There's no need to "download the track to the device" the players stream it on demand, just like Pandora or Spotify. To start your configuration testing: While at home with the phone on your WiFi, use a client on the phone (UltraSonic, which I linked, is one of many), point the player config at your unRAID box's static IP and *sonic port. You should be able to login with the *sonic account you created & start browsing your media library within seconds. Once that's working, turn off the phone's WiFi (to force access from outside your home network), set up a port-forward in your router to point the incoming traffic at your unRAID box (IP:Port), reset the phone client media player config to point at your home's external address, then start browsing your music collection from the phone. Hit play, and the streaming automatically begins. You may need to use a free service to set up a domain name for your dynamic IP as provided by your ISP. For example, I use changeIP.com, but there's also DynDNS and many others. The various *sonic servers also seem to have their own sub-domaining available that you can set in your *sonic configuration to give you a nice name to point the phone client to. If you have a static IP address from your ISP, just point your phone at the static IP address in the client software config.

Thanks for the feedback. Did the following: - Left menu hovering time accellerated - Left menu bouncing effect removed - Apps text centered - Apps text use padding instead of line-height Notifications: choose summarized instead of detailed LT logo: opens a popup and allows users to respond directly to LT Other requests will take in consideration.

Install this first Then install this and this by following this tutorial https://www.linuxserver.io/2017/05/10/installing-nextcloud-on-unraid-with-letsencrypt-reverse-proxy/ to get it all working together.

What filesystem are you using on your data disks? Before switching to XFS I had numerous timeout issues with RFS, and Windows would report weird errors.