itimpi

The .key file goes into the ‘config’ folder on the flash drive.

This should mean that you have not successfully linked the docker container to your Amazon account, but your earlier answer indicates you have connected so there is some contradiction.

You will need to set cache as primary storage array as secondary storage mover direction to be array->cache disable (temporarily) docker service run mover to get any files for the appdata share on the array transferred to the cache when that completes set the secondary storage option for the appdata share to None (if not already done so) enable Exclusive shares under Settings->Global Share Settings to get improved performance. The next time the array is started the appdata share should then be running in Exclusive mode. Reenable the docker service.

Not quite sure what you are saying is not connecting? Some questions: Have you successfully installed the MyMedia for Alexa skill into Alexa? Can you get the MyMediaForAlexa docker GUI pages up? Have you used the GUI pages to connect the docker to your Amazon account? Have you paid for a licence? Is the docker correctly configured to point to where your audio files are stored? Does the docker container GUI say it has successfully indexed files?

You can only get a BTRFS RAID1 storage in a BTRFS multi-drive pool, and it is not possible in the main Unraid type array as in that each drive is a single self-contained file system and this is not going to change. That is why the main Unraid array can have a mixture of different file systems. What is expected to change at some point is the requirement to even have the main Unraid array - instead that will become just another pool type and you can then mix and match pool types as you want.

Is the rebuild finished - I thought you implied it had failed. In the earlier diagnostics I could only see the rebuild starting - not it completing or being cancelled.

It is worth pointing out that if you have Turbo Write enabled you can write directly to the array at speeds of that order of magnitude. Probable a better way to handle your requirements anyway.

The parity disk also seems to have 44 reallocated sectors which is never a good sign if this is a newish drive.

I do not see that happening as it has been standard behaviour in Unraid for a very long time now. What is your Use Case for creating top level folders anyway? As a workaround why not create one share (and set it to only exist on the drive you want) and then create further folders within that.

I am a bit confused about what you are trying to do? You mention formatting a disk for parity but that is weird since parity has no file system. Have you actually set up a parity drive as once you have done so you cannot add new data drives to the array without first wiping their contents. If you have NOT assigned a parity drive then it is possible to get drives added to the array without losing the contents as long as they were previously formatted and partitioned by Unraid.

This is a known issue with that model of SSD - it appears that under certain circumstances the temperature gets briefly reported incorrectly. I think it was a firmware bug in the SSD so you might want to check if there is a firmware update that fixes the issue.

Your screen shot shows you ran a correcting parity check which made the parity agree with the data drives. Had you by any chance had an unclean shutdown earlier - they would normally cause a few sync errors. You should then not expect any further errors on the next check Was this a manually initiated check or a scheduled one? Just asking as we normally recommend that scheduled checks are set to be non-correcting so that faulty hardware will not end up corrupting parity before you are aware of any issues.

Jan 24 14:14:09 AKserver kernel: usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd Jan 24 14:14:11 AKserver kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jan 24 14:14:11 AKserver kernel: sd 1:0:0:0: [sdb] tag#0 Sense Key : 0xb [current] Jan 24 14:14:11 AKserver kernel: sd 1:0:0:0: [sdb] tag#0 ASC=0x47 ASCQ=0x1 Jan 24 14:14:11 AKserver kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 00 37 74 00 00 08 00 00 Jan 24 14:14:11 AKserver kernel: I/O error, dev sdb, sector 3634176 op 0x1:(WRITE) flags 0x104000 phys_seg 253 prio class 2 Looks like your cache drive dropped offline - a not uncommon occurrence when using USB connected drives.

This is not how it works although I guess it could be a feature request. You need to go into the share settings and make sure it set to only be on the cache.

The fact the drive is disabled suggests a write to it failed. You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. it is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog. i am a bit worried by the fact you mentioned a format - that is not part of the normal process of replacing s drive. Users have been known to lose the contents of the emulated drive by accidentally formatting it and end up rebuilding an empty drive. However the figures you quote seem about right so maybe this is not what you did but I am not sure what you used to do the unneeded format as the rebuild process would wipe away any format anyway.

Once a disk gets disabled (red ‘x’) for any reason then rebuilding it is the way you clear this status. You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. it is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog. The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.

I have a Windows 7 VM that I boot and run from a VMDK.

I was thinking you were trying to boot a VM that was running Unraid in the VM. If that is not the case then the flash drive is not needed.

Have you made sure that your remote client and your server are not on the same subnet as this can mess up name resolution. For this reason it is often not a good idea to have your home network on the 192.168.0.x and 192.168.1.x subnets as these are very frequently used elsewhere as they are the defaults for the vast majority of routers.

If you have User Shares enabled then it is normal for every top level folder on a drive to automatically become a User Share with default settings and Unraid has always worked like this.

Yes. Click on the boot device on the Main tab and you can then set the SMB security setting for exporting it as a network share with the level of security you want to apply.

Do you mean shares that ARE exported, but set to not be visible? For those you need to know the name to access them. if you really mean Export=No, then they are only accessible locally on the server.

I assume the disk is also showing with a red 'x' indicating it was disabled so then the answer is Yes. The rebuild will put onto a physical disk exactly what is showing up as being on the emulated disk. On successful completion the disabled status will be cleared and the disk no longer be emulated. Really up to you as the emulation process makes it look like the disk is present at all times. Only thing to bear in mind that you probably do not want to do this while actually running the disk rebuild as the rebuild and checksum processes could dramatically slow each other down.

Not sure what is going on as I could not see any attempt to build parity in the diagnostics, and the first one shows the risk going offline almost immediately. Are you sure the diagnostics were taken before rebooting (which resets the logs)?

When docker container has its own IP the only way you can change the port is for the container developer to make a change within the container.