jus7incase

when backing up the flash drive content, the file config/super.dat is renamed to config/super.dat_CA_BACKUP. When you rebuild a flash drive from scratch and copy the config folder over to the flash drive it is easy to forget to rename super.dat_CA_BACKUP back to super.dat. If you forget that the server will not assign the drives and report the config as "stale". This is highly confusing and should at least be documented in the UI. It would be better if the file gets automatically renamed back by the pulgin after copying it to the backup location!

Found the problem with some help of Tom of LimeTech. CA_BACKUP renames super.dat into super.dat_CA_BACKUP. Thus the drives are not assigned. after renaming it back up super.dat the server would start ok and config is not reported as stale any more. the array started and parity was reported valid, so I canceled the parity check that was kicking in.

This problem is still there.

I received the license key for the flash drive and now unraid tells me "stale configuration" and none of the drives are assigned to any slot. Is there a way to make unraid accept the config files from the backup to assign the drives? Just seems the safer option compared to the exercise of looking up the serial numbers to assign the drives...

I just formatted as FAT32 with GPT and went into the boot options of the BIOS and now have: 1) flash drive UEFI 2) flash drive 3) UEFI boot shell and the machine boots. I am not sure though what path it used to boot UEFI or legacy, since I have enabled it to use either UEFI or legacy. At least it proves that FAT32 works with GPT boot record. Of course my license needs to be replaced, the software says "too many devices". I am sure the support will solve it like a breeze.

What boot record are you using on these FAT32 drives? MBR or GPT?

I will do. I have not changed the boot order since the time when it worked, though. I do not expect any new information from this and would only post a result if there was a misconfig. Could I alternatively prepare a flash drive using the Limetech Unraid USB Creator and copy the crucial config files from the backup to the flash drive? If so, which files should I copy?

Thanks for the info. I formatted as FAT32 with a Master Boot Record and copied the files from the backup to the flash drive. Then I ran "make_bootable_mac" and it asks whether UEFI boot should be enabled. I responded "N", but the server does not boot from the USB flash drive. Note: UEFI boot and legacy boot are enabled in BIOS. This brings up a few questions: (1) Does a Master Boot Record actually support UEFI boot? Or does UEFI require a GUID boot record? (2) Can a GUID boot record be used with FAT32? (3) Why is the system not booting from the flash drive? Could I alternatively prepare a flash drive using the Limetech Unraid USB Creator and copy the crucial config files from the backup to the flash drive? If so, which files should I copy?

The stick is dead. But I have another stick, which in need to register for the unraid license. So the permissions and ownerships are not of importance?? Shoudl I just format the stick FAT32 and copy the files onto it, or shoudl I ZIP the files and use the unraid falsh drive installer to create the stick?

Hi all, when I powered my unraid server up after a 2 week absence, the USB boot stick was dead. I tried to look at the stick on my mac, but it did not recognize the USB stick at all. I found this to re-build my flash drive: https://wiki.unraid.net/UnRAID_6/Changing_The_Flash_Device There they need a backup as a ZIP file. I do have a backup of the flash drive, but as it is with backups, I did not test them. So what is the actual problem: The backup is created using the Backup plugin and written to a local share. This share is synchonized to a Synology DSM share using Syncthing on unraid and the Synology DiskStation. On the Synology DiskStation, all files written by Syncthing have the ownership "sc-syncthing:syncthing" and permissions look like 644 for files or 755 for folders. May I use the above cited procedure using my backup with quirky owenerships and permissions? What whould be the best / safest way to proceed now? Your help is appreciated!

It would be great to have logging in the homebridge GUI container. I ooked for the log file but couldn't find it. also systemd is not running, so currently I saw no possibility to get the logs into the UI. If something doesn't work you definitely need the logs to solve the problem. Could you please extend the container to provide the logs and also set then in the initial config.json?

Hi! in the TVHeadend configuration the storage path setting for timeshift data is coming as empty. As a result, the timeshift buffer is managed inside the docker container filesystem and this may grow larger than intended. This may not be what everyone wishes to do. I thus suggest to have either in the standard setting a storage path set for timeshift as: /recordings/timeshift As a result the timeshift buffer is stored in the path where the DVR recordings go. Alternatively you could introduce a separate path for the timeshift buffer and as well a respective mapping for the container config. Just my 2 cents...

Hi altogether, to be honest I was not reading all 80+ pages of this upport thread.. I would like cache directories to initially scan all my disks. Is it going to do that automatically or is there something that I need to tune, so that it does a complete tree walk? Thanks!

Dear all if I understand correctly the "Docker Safe New Perms" is installed by the plugin "Fix Common Problems", so I post my problem here. I have run Docker Safe New Perms on all disks except for the Cache disk (nothing to be moved). Then I wanted to use unBalance to move the content of one disk to another disk. During the planning phase unBalance would complain that it found directories with improper permissions and I shall run "Docker Safe New Perms". So how can this be since I did run "Docker Safe New Perms" in advance. It turns out that unBalance considers existing Set-U-ID oder Set-G-ID bits as problematic, and "Docker Safe New Perms" does not clear out these bits. I do not know whether these bits are actually a real problem for the unBalance procedure. But if they are, then "Docker Safe New Perms" should remove those bits, e.g. by setting the permissions to 00777. (Note the leading 2 zeroes! Yes this is correct, with just one zero it will NOT clear those bits!) This can be done manually as long as "Docker Safe New Perms" does not do it: find /mnt/disk?/ -type d -and -not -perm 0777 -exec chmod 00777 {} \; However, if those bits do not create a problem with the unBalane procedure, the unBalance should not report them as an issue. if you search like this, you will find the directories where SUID or SGID are set: find /mnt/disk?/ -type d -and -not -perm 0777 This is not what we want if we do not want to report those directories. Instead it should be used: find /mnt/disk?/ -type d -and -not -perm -0777 Note the "-" (minus) character in front of the 0777. Now additional bits being set will not be reported! It would be great to get feedback from the author of unBalance whether these bits should be cleared or whether the should rather not be reported. In the first case it would be good to get feedback from the author of the plugin "Fix Common Problems" whether clearing of the SUID SGID bit for directories can/will be implemented. I am going to cross-link both postings in both support threads. Fix Common Problems thread:

Dear all if I understand correctly the "Docker Safe New Perms" is installed by the plugin "Fix Common Problems", so I post my problem here. I have run Docker Safe New Perms on all disks except for the Cache disk (nothing to be moved). Then I wanted to use unBalance to move the content of one disk to another disk. During the planning phase unBalance would complain that it found directories with improper permissions and I shall run "Docker Safe New Perms". So how can this be since I did run "Docker Safe New Perms" in advance. It turns out that unBalance considers existing Set-U-ID oder Set-G-ID bits as problematic, and "Docker Safe New Perms" does not clear out these bits. I do not know whether these bits are actually a real problem for the unBalance procedure. But if they are, then "Docker Safe New Perms" should remove those bits, e.g. by setting the permissions to 00777. (Note the leading 2 zeroes! Yes this is correct, with just one zero it will NOT clear those bits!) This can be done manually as long as "Docker Safe New Perms" does not do it: find /mnt/disk?/ -type d -and -not -perm 0777 -exec chmod 00777 {} \; However, if those bits do not create a problem with the unBalane procedure, the unBalance should not report them as an issue. if you search like this, you will find the directories where SUID or SGID are set: find /mnt/disk?/ -type d -and -not -perm 0777 This is not what we want if we do not want to report those directories. Instead it should be used: find /mnt/disk?/ -type d -and -not -perm -0777 Note the "-" (minus) character in front of the 0777. Now additional bits being set will not be reported! It would be great to get feedback from the author of unBalance whether these bits should be cleared or whether the should rather not be reported. In the first case it would be good to get feedback from the author of the plugin "Fix Common Problems" whether clearing of the SUID SGID bit for directories can/will be implemented. I am going to cross-link both postings in both support threads. unBalance support thread: