denishay

OK. I guess I just got unlucky then. Every time I've tried anything beyond 32GB (always with the USB Creator in Windows 10, 2 times with 2 different 64GB drives and one time with a 128GB one), it failed. I understand it's a small sample size [ 3 in my direct experience), but it could have also to do with the fact that that was with rather old harware on the unraid server (fairly ancient motherboard) ]. Thanks for the confirmation though.

Agreed, but starting the array without the old cache will "force" unraid to create those folders where available, hence change the settings. I know, that's what happened to me on a test setup not long ago

I'm pretty sure it was not just about the drive but retrieving the whole config as it was before, including docker configs, etc. Adding the drives only will not retrive that

Hi, Yes there is. • First, stop your current array • Go to settings > docker and disable • Go to settings > VM Manager and disable • Add your old cache drives to the array as they were • start the array IMPORTANT: do not enable dockers and VMs yet • Go to the array with a decent file manager (I rather recommend Midnight Commander, aka mc from the command line, but it's up to you) and delete the newly-created appdata and other folders which will have been created on the array as there was no cache • Once this is done, you can enable dockers and Vms, but make sure you select the advanced settings and point to the files which should now be back on your cache drive I hope I made things clear enough. Let me know if not

Hi everyone, Sorry for the "thread necromancy", but I hesitated a long time between refreshing this topic a bit and creating a new one. For the mods, let me know if you prefer a new thrread to be created, I'm fine with that. I have used for many years the small "mini" usb drives as boot drives to avoid having something long and fragile sticking outside my unraid server cases. But then, even though I stuck to reputable brands, it seems that they always end up after a few years as "read only" [thus it becomes impossible to update plugins]. Fair enough, I went on now to use internal motherboard usb2-to-usbA adapters and "longer" sticks. To avoid the prolonged overheating that seems to break those mini boot drives (too) quickly. But then, it struck me, and please correct me if I'm assuming wrongly, but... The official recommendation is to keep using only "USB2" drives from reputable manufacturers, and at a maximum of 32GB. So... I am not disputing that *some* among us have different boot drives, but it seems that there is a largely mixed bag of bad experiences with anything non-USB2 and/or larger than 32GB. And nowadays, it is becoming harder and harder to get such devices [still possible, but requires a LOT of double and triple-checks]. At some stage, it will probably not be possible anymore. Shouldn't we be getting a bit more love regarding the choice of USB boot drives? (I'm not talking about wasting resources on SDD or aything else using precious SATA or PCIE ports, just USB). Can we see an official support for USB3 drives of larger capacity? It seems to me when browsing online sellers than 128GB is kind of the "new" minimum.

Hi, Sorry for the reply in English, but is an English-pseaking forum. Each nextcloud docker will have its own configuration requirements. I highly suggest you read the documentation or support page for the docker you are using. That way you will know where you want to store your Nextcloud files. You will not get a final reply which fits all cases I'm afraid. Also, showing a Windows explorer window doesn't help much here. Also, even though there will be a "files" subfolder for each and every Nextcloud user, Nextcloud will most of all store its content and metadata in a database (mySQL or MariaDB one usually). Files alone are not enough.

Several notes on my side. First, the "cache". Why? Your array is made of SSDs, why have a separate, most probably slower SSD as cache? Unless you're rocking 10GB/s in that tiny box, any SSD, even a SATA one, will more than max a Gigabit connection (and a 2.5BGps one). You mention a "backup" server, but it seems to be more a separate "test" server than a backup repository, is it? Or is it one that will be used as a target for backing up data? Quick questions: • Is the "cache" also a SATA SSD? If yes, I would probably have used that last SATA slot to get a larger raidz1 ZFS pool • I don't see the main array anywhere in your screenshots. Did you just hide it, or did you find a way to NOT have a main array?

A quick "up" for this one, as I am looking for the same. If anyone has any more recent info, it is most welcome!

OK. Just to be clearer, it is due to the way SMB is configured/implemented/whatever on Unraid by default. Most of us have not played with those settings. Using anything else than SMB for transfers or any other system than Unraid with SMB all pretty much max out the Gigabit network. That was the whole point of my post above. I guess I didn't make it clearer: if there are better settings to be made, why are they not set by default on new setups? In my specific case, I tried modifying the SMB settings, but only got worse results (15Mb/s or less with Multichannel for ex.). As I said earlier, I have made my peace with that. I don't care and don't really need more. But claims that there are "no problems" with the way Unraid configures SMB by default and trying to have *users*/ go through a complex game of trials and errors is just not right. If "optimal" settings exist, why are they not set by default and/or some warnings issued?

I do not mean to rain on anyone's parade, but for me and at least 4 other friends on Unraid, it is not the case. Unraid is consistently "slow" on SMB transfers, with anything between 30MB/s to 80MB/s max on a Gigabit LAN. If you refer to this Unraid vs TrueNAS comparison on Youtube above, you will easily see that the SAME HARDWARE and network performs 3 times as fast (yes, even after he re-did the same tests using ZFS on Unraid too. Now... I love Unraid, and performance is still "OK" most of the time for what I use it for (mostly media streaming), but no, sorry, SMB peformance on Unraid is notoriously bad for a reason. Acknowledging that would probably be a step towards having that thouroughly investigated rather than trying to find out what's wrong on the "user side" pretty much every time. I'm not saying that things cannot originate from the user's setups, but for many of us with many different systems and sometimes different servers, it is evry apparent that anything to and from Unraid SMB shares *is* slow. Much slower than pretty much anything else. It's a good thing it has loads of other qualities, but if SMB performance could get some love, it would make Unraid so much better!

exact same issue for me

Would love any pointers as to which company that is though...

Yep. Have that on my test server. One ZFS pool mounted to replace the only disk in the unraid array: mount -R /mnt/zfs /mnt/disk1 I run that at the start of the array. Works well so far. Only limitation with the ZFS plugin is that dockers and VMs had to be on the cache pool. Will try now with 6.12 rc2 to see if that can be changed back to the array

stupid questions, but.... you do have another GPU at all on this setup? If you are trying to pass through the only GPU, the system doesn't have any left

Exactly that. Plus, given the equipment you have + lots of RAM, ZFS would come as the ideal solution to maximize performance/redundancy here. The "current" unraid parity system would only slow down I/O a lot (while still probably being bottlenecked by your 6GB backplanes anyway). Get onto the 6.12 beta "test" branch to try and experiment before you put any real data in there.

Exactly. Redundancy is not backup. It is "safer" main storage, but never a backup. Even a single backup on another media is already very risky/unsafe. Parity will protect from (most) hardware failure for example, but not from viral infection, not from bit rot or anything that would mess up with files. Having another "unattached" copy will allow you to restore a known good (backed up) version. In the same spirit, synching is not backup either.

I would love to get more info on that too... tried ZFS on a second "test" server, and would love to share some datasets, Without sharing, the ZFS pool looses all its interest

Hi Lamp! did you find it in the end? I am facing exactly the same problem now. Can't find that is doing this

Quand tu as une nouvelle clé, tu peux toujours transférer ta licence (dans le mesure de 1 foi par an automatiquement, au delà, il suffit de justifier ta demande au support de LimeTech). La licence est l'identifiant unique de ta clé. Un backup ne t'aurai servi à rien car la licence générée aurait été invalid pour ta nouvelle clé. Tu vas trouver l'option pour activer ta clé actuelle et désenregistrer l'ancienne dans Tools > Registration. Tu devrais y trouver une option "Replace Key".

Had a similar problem with 2 TB Samsung 870 EVO. They were happily in RAID1, then suddenly without explanation went into "single" mode and cache was showing the wrong size. No amount of balance worked (the option did reset without letting me run a balance and the command line equivalent didn't work). I had to change my shares/docker/vm to not use cache, removed both drives, formatted both, then created cache again with one drive, copied data back and then added the second one. There I had the RAID1 balance working. Everything is back in order.

OK... I have found a solution, and writing it here as it may help others troubleshoot passwordless SSH connections. I knew I had done everything right and couldn't find why it was working with passwords entered bu not without. The whole key is in the "-v" (verbose) option of the SSH command which allowed be to see all the steps and find out what was wrong. As a reminder, host is unraid and the remote guest is a raspberry pi under debian 10 lite (without desktop). As you can see, all it took was to rename the public certificate and upload it to the host. To do that "properly" without to have to set permissions, you can use the ssh-copy-id -i <path+certificate_name> user@host command. So from now on, if you are having issues with your certificates or passwordless SSH connections, you know how to look for what's missing or not working!

I'm at a loss after 3 days of research and many reboots on this. I am trying to create a "safe" connection between my unraid and a raspberry pi which will ultimately be remote. I am using raspbian lite 10 on the raspberry. I have already installed wireguard on it and it connects to unraid successfully at each reboot. So that's for the "safe" tunnel in between the two. Unraid (10.253.0.1) can ping and ssh into the raspberry pi (10.253.0.3) using the IP address between brackets, and the other way around. So SSH works wonderfully... but only by entering the password. I created the ssh public keys [using ssh-keygen], added them to the authorized_keys file on each endpoint [cat raspberrypi.pub >> authorized_keys], but to no avail. Everything works fine, but the password is always required. I have tried of course to disable the password login on unraid [in the settings section once the SSH plugin is installed] to try and see if it would force the usage of the predefined public key stored, but nope, the connection then fails. I want to be scripting some rsync later, so I absolutely need to have the passwordless login working. I have tried many tutorials around, and I think I understand the mechanisms quite well. As far as I can tell, I have done everything necessary, but I don't understand why the password is still required for any SSH attempt I do (either way). I have tried also all the different values for chmod on the different files and folders, but no combination seems to work. Worthy of note, I am using the root account on each side, even on the raspberry (so not the pi account, I have enabled root, but even other "new" users created with super user privileges still have the same behaviour and the password is requested). Any help would be greatly appreciated

Hi, You are right. It is not possible anymore. The "for business" line of Crashplan never allowed that. And Crashplan discontinued their older solution for consumers. So you cannot do that anymore. A pity as I see lots of added value there, but I also understand, knowing that their cloud backup service isn't limited in size (or you could potentially backup many workstations to one, then have a subscription only for that last one).

What I do is that I have indeed Nextcloud have its own files on /data and I create an extra mapping pointing to my unraid data that I add as external storage on Nextcloud.

You're welcome. Yes, sorry, my nextcloud is using an older PHP (I downgraded it manually for an older version update which wasn't supported with PHP7). Had even forgotten about it since.