fplanque

Yes I understand I can docker exec into the container but then all I have is a linux shell prompt. What I'd like is to have a prompt from the server. Something where I can type "/help" or "/time set day"...

hi, I am installing this for my kids but I don't know much about how the Minecraft server should work. I can connect to it from the game. That is a good start. To configure the server, I tried the web UI but when I type help, there is more than one screen and no way to scroll back... (?) I tried to follow this manual page: https://github.com/binhex/documentation/blob/master/docker/faq/minecraftserver.md ... but the console thing does not seem to work. Is there a way to use a console that is not through webui? Thank you.

I guess this has been discussed before but I can't find the post, sorry (but will happily take links to previous discussions zfs has a good reputation because it's been there for a long time, yet there have been quacks recently with 6.12.4, 6.12.5, 6.12.6). btrfs has a bad reputation because of issues in the past, yet facebook/meta run their whole infrastructure on btrfs only. So, religion apart, when does it make sense to choose zfs over btrfs? CoW, snapshots, compression are supported by both. My understanding is that the one thing that zfs does better than btrfs is fixing issues in real time as they happen, while btrfs needs you to run a periodic scrub in order to fix things. The tradeoff, in my understanding, is that zfs uses more resources, especially RAM. zfs also supposedly has a better cache design but I could not find any benchmark where it shows that zfs actually has better performance than btrfs on an equivalent system. It seems than many people where waiting for unraid to support zfs, but what does it really change over using btrfs in the context of unraid? Thanks for your insights.

Many times, if you reboot your mac and try to access time machine again, it will be able to connect and show you more than 2-3 days. If you have a standard spinning drive for your network backups, you may need to wait up to a full minute before the additional days appear. Personally I opted for SSD+zfs

I've spent several days moving my time machine backups from old Apple Time Capsules to Unraid. (MacOS Ventura + Unraid 6.12.4) (I specifically wanted to do this before upgrading to Sonoma, will give Sonoma feedback later) Here's what I learnt: 1) When backing up to a network share, Time Machine creates a virtual drive (.sparsebundle) on the network and then proceeds to manage that whole drive remotely. This is inefficient as hell (but this is how TM manages to save space by hard-linking unchanged files between one backup and the next). This makes network backups an order of magnitude slower than backing up to a drive that's directly attached to the mac. 2) It seems it may be even more inefficient if the backup is encrypted, i-e: when the .sparsebundle is encrypted. 3) Because of that inefficiency, I decided to compensate by backing up to an SSD drive in my unraid. No need to use nvme drives, it will be totally overkill in regard to the speed at which the mac will send backup data. I opted for the cheapest high capacity SATA SSD drive(s) I could find on Black Friday. 4) I am using that SSD as a standalone drive/pool, not protected by anything for 2 reasons: my array parity is not SSD and would slow down writes my time machine strategy is to back up to 2 different unraid boxes in 2 different parts of the building. (This gives better protection than 2 drives mirrored in the same box + allows to back up whenever one of the 2 unraid boxes is down because I'm playing with its configuration...) 5) I am using zfs for the SSD (with LUKS encryption). I also use zfs compression. This only makes sense if time machine does not encrypt its backups by itself. If TM encrypts, then zfs can no longer compress it (for example because strings of nulls will be garbled), It tested this. I get about 20 to 25% compression when letting zfs compress on the server compared to when trying to compress an encrypted backup (which results in close to 0% compression). 6) I observed no slow down due to zfs compression (but I observed more space for backing up more history ;). I think I do see a slower back up with a mac/tm-encrypted backup to uncompressed zfs but I need to test this more. 7) If the backup is not encypted by TM but encrypted by zfs, it will be encrypted at rest but will be clear in transit between mac and unraid. If that is not desirable, it is possible to enable encryption at the SMB level. To do this, first type this in mac terminal: `smbutil statshares -a` . You should see SMB traffic is not encrypted by default: ``` SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED SMB_VERSION SMB_3.1.1 SMB_ENCRYPT_ALGORITHMS AES_128_CCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_128_GCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_256_CCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_256_GCM_ENABLED > SMB_CURR_ENCRYPT_ALGORITHM OFF SMB_SHARE_TYPE DISK SIGNING_SUPPORTED TRUE EXTENDED_SECURITY_SUPPORTED TRUE UNIX_SUPPORT TRUE LARGE_FILE_SUPPORTED TRUE OS_X_SERVER TRUE FILE_LEASING_SUPPORTED TRUE MULTI_CREDIT_SUPPORTED TRUE ``` Then go to Unraid > Settings > SMB > Extra Config and enter: ``` server signing = mandatory smb encrypt = mandatory ``` Then check on the mac again: ``` SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED SMB_VERSION SMB_3.1.1 SMB_ENCRYPT_ALGORITHMS AES_128_CCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_128_GCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_256_CCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_256_GCM_ENABLED > SMB_CURR_ENCRYPT_ALGORITHM AES-128-GCM SMB_SHARE_TYPE DISK SIGNING_SUPPORTED TRUE > SIGNING_REQUIRED TRUE EXTENDED_SECURITY_SUPPORTED TRUE UNIX_SUPPORT TRUE LARGE_FILE_SUPPORTED TRUE OS_X_SERVER TRUE FILE_LEASING_SUPPORTED TRUE MULTI_CREDIT_SUPPORTED TRUE > ENCRYPTION_REQUIRED TRUE > SIGNING_ON TRUE ``` This will give you encryption in transit (for all SMB traffic, not just Time Machine). Additional considerations: 8. Using an SSD on Unraid will be faster for backing up and also for restoring compared to a spinner on Unraid (or Time Capsule) of course, but it will also be faster than a spinner attached directly to the mac. I am now considering dropping the spinner I have attached directly to the mac. 9. Time Machine is a b!tch for reconnecting to your backup when you need it the most (i-e when you need to restore a file). Here is a shortlist of what to do if it doesn't want to play nice: Disconnect all network drives in the finder, then reconnect, then open the .sparsebundle volumes manually (will prompt for TM password if encrypted). Once this is done, enter time machine again. If that doesn't help, you can also enter time machine history directly from a .sparsbundle that you have opened in the finder (there will be an "open with time machine" button in the Finder. This will show you only the history that is backed up to this specific bundle (if you have several) but it can be a time saver. If that doesn't help, reboot your mac before trying time machine restores. A freshly booted mac tends to connect much more easily to all its shares (may be a bug in the OS network layer) Occasionally you may need to restart SMB on Unraid, or even restart the array, or even restart the server. I always ended up being able to access my full file history after those steps. 10. However when a backup disk gets errors, it will frequently invalidate your whole .sparsebundle. This is "TimeMachine over network share"'s biggest weakness. Using mirrored zfs raid-z drives may help with that but not only did I not invest that much in SSD drives, I also don't have enough SATA ports left I might try it in the future though.

@Nicodem Have you tried accessing the share through the finder and create a random folder on it? @rbhalla Same as above + sadly enough, oftentimes you need to reboot the mac to clear some caches for network connection + occasionally it helps to reboot unraid.

@Cosine I also had the issue of the my new ASUS motherboard royally ignoring my unraid USB key when booting... (and sometimes recognizing it just to ignore it on the next reboot). I tried different USB keys, changing all the wrong UEFI settings (CSM compatibility, etc...), using all USB ports, especially USB 2, "EFI" vs "EFI-"... none of all that made a difference... I also pulled my hair out... way past the 4 hour mark... but finally found the culprit after 2 days: In ASUS UEFI BIOS, you want to DISABLE the "Fast Boot" (it's enabled by default). Mind you, there is zero noticeable difference in boot time, but it now recognizes my USB boot key every time. For reference, to be clear: EFI boot works fine, all USB ports ( 2.0, 3.0, 3.1, 3.2 ) work fine. (I think the solution accepted before should be untagged to avoid confusing future users of ASUS motherboards).