RT87

Thanks a lot for the /dev and /mnt path clarification! Okay, I see, btw also thx for that info! Is there some switch with which to tell unraid to NOT emulate a disk right away, but rather give errors on failed reads/writes first? That in combination with a "emulate failed disk" button would be a workaround to avoid disabling drives due to mere hickups. Furthermore: If any drive becomes disabled, but it is not truly broken, i.e. such a hickup has occurred: Can Unraid "catch up" to writing the data (from the parity-data) to the (temporarily) disabled drive, or, if at any point in time any drive got "disabled", do I automatically have to rebuild the entire parity/disabled disk?

okay... but I do get SMART reports for bad sectors etc and also identifiers, although I do not know to which degree the uniqueness goes. By "non-standard size" you mean this HPA issue, or is there another problem? Performance isn't much of an issue for me, even for parity checks. Is there a way to prevent any write operation if a (random) disconnect occurs? "Frequent" parity rebuilds would be painful to my usecase. While on the subject of parity, is there a thread where I can read how it works in practice? I know the XOR theory and such, but concretely I am interested to know how I could mess it up accidentally. E.g. am I save as long as I do mv/cp cmds withing the /mnt structure? In other words: Hands off the /dev path!! And if parity is broken, e.g. due to a disconnect, and lets say during this disconnect a 1GB file gets written... Is partiy broken altogether? Or just for a "1Gb range" on the other array disks (however many files that are?

At least I had no disconnections so far... Is there a comprehensive list of why-not-to-use-usb reasons ^^? Not kidding, btw! So... if I were(!) to continue USB, how would I avoid this in the future? Just buy N+1 TB drives were N TB is the single largest array drive? Or can I assume that same-vendors drives will always work...?

okay, thx... how about "shrinking" the array disk?

So there is no way to know if the issue will be resolved before hooking it to an SATA port?

okay, but for that I would have to shuck the drive, right? Which I can do, but I'm rather uninclined to, if this might not fix it... If I cannot figure that out beforehand, I think it might be better to cut my losses and send it back/resell it :(.

It is indeed a WD Elements drive.... The other one is Seagate (next purchase will be seagate too, I think, I dislike both the HPA issue and the drive vibrations, which are rather strong for a 2,5" 5400 rpm drive imho, but that's another matter). Can I find quickly out, if removing the HPA will do me some good (beforehand, that is)? How would I best go about removing the HPA? I have found several posts regarding this issue, but I am still somewhat unsure...

ahm, would that I could, except that... okay, here it goes: My unraid server is an old notebook of mine, with external 2.5" drives simply connected via usb... I know, maybe not the greatest solution, but it actually has some advantages (e.g. low power consumption, built-in UPS aka battery), and I do not care much for speed, since I mainly use it as a centralized storage for different devices with usually very little I/O load. changing usb ports didn't help, no idea if that might help to begin with. another note: if I have to hook said drive to an actual SATA controller which goes directly to the MB, that could be done quite easily... however, if the drive would have to "stay" there, i.e. I cannot go back to usb after that, that wouldnt work

hi, sadly I appear to have a similar issue. I am trying to use two 5 TB drives, however my supposed-to-be parity drive gives me this: hdparm -N /dev/sda /dev/sda: SG_IO: bad/missing sense data, sb[]: f0 00 0b 04 51 40 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SG_IO: bad/missing sense data, sb[]: f0 00 0b 04 51 40 01 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 9767475632/1(1?), HPA setting seems invalid (buggy kernel device driver?) The "1(1?)" for the max sectors in particular really confuse me. I'd really appreciate it if anyone could help me with this issue. Also: Since I don't really care for a few additional sectors, I would also be glad to reduce my array disk by X sectors, if that would is even possible... Side note: I cannot switch the array and parity drives.

Could this be used to implement a feature as requested by myself here:

Hi, I would love for an additional "cache copier/syncer" as an addition to the existing mover. What exactly do I mean by that: Say I only want to use one large SSD cache drive (instead of 2 or more to get an array-like redundancy, since large SSDs are still somewhat pricey and, of course, take up space and ports). I would like to have all my docker/vm/often used data ond the cache drive, but I would also care to have that cache-data backed up on the standard array/data drives on a regular basis. Hence, I would like for a nightly backup to the array to occur, but not with moving, but copying/syncing instead. Ideally, the share which is used for this would be read-only to all users (a "cache-sync-share", if you will), so only the syncer can write to it (root definitely shouldn't, but could). However, the users/root CAN use it to restore the data from this share (in case of SSD failure), or, of course, delete it entirely, This would be very helpful, because I could save on SSDs without sacrificing redundancy. I personally do not care about the performance of the syncer, because this job would occur during low-to-none-load times. I also know that I can probably build this very feature on my own, using the "cache: only" setting + rsync/rclone or something similar (most basic: cp -uvr + crontab + remove data-singles without cache-equivalent), but I really feel like this is something many people would benefit from. Maybe this request will get a few "+1"s, which would be nice, but otherwise I would also be happy to just script-kiddie implement this on my own ;).

+1 for docker compose Not for the featureset, but for universality and ease of use/migration.

I agree, so +1 from my side. Yes, I know I can pretty much do the same thing by using Nextcloud or something similar, but still, it would be nice-to-have and reduce boilerplate.

Ah, too bad... hopefully it will soon! Since I am "forced" to use IPv6 for such matters (I despise paying my ISP a premium for an IPv4 ^^), I feel a bit discriminated against ;).

Oh, I see... and I agree, handling the entire unraid server as "exposed host" would be most unwise, especially if you are running privileged containers and such (which I am). But no, I have only opened port 443, nothing else. My router has a separate checkbox for allowing pings to a specific machine, which (to my knowledge) doesn't even know ports. So thanks for clearing that up! Back to my original question: Does myservers support the IPv6 protocol (or is planned to)?

Well, given the obstacles, they should have a hard enough time. Besides, they would need to figure out my IP first. Given that the IPv6 pool is "reasonably hard to scan", I wish them good fortune ;). After all, we're not talking about the IPv4 pool of AWS, where bots hacking sandbox systems in that IP range has been common for years and years. But still, how exactly is this setup different from what myservers is trying to do? What precisely makes the myservers approach "secure"? Or am I completely mistaken?

Nope, no VPN. However, I have obviously put as password in place, plus its a lab with no important data whatsoever, if thats your concern. None the less, I thought this was basically the idea behind this feature, access to my entire server from anywhere, was it not?

There appears to be a bug in this package: If I use the "br0" interface for the connection, i.e. the container obtains its own IP address from the DHCP server/router in the network in which unraid lives, the http/https ports that I specify are ignored. The default values, e.g. 8080, are used, which is bad in case you just want ot use normal http/https behaviour (but with its own ip) and your router doesn't allow portforwarding to another port.

Hi, I'm unsure whether this issue has been already addressed (if so: sry!), but online my access is marked as "local access", although I have configured the portforwarding etc. (clicking on this link then simply leads me to my local IP address). However, my ISP only gives me a DS-Lite connection, i.e. I do not have a true IPv4, but only the one to the server of my ISP (for which portforwarding obviously will not work ). To combat this, I use a public IPv6 for my unraid server, for which portforwarding is indeed configured (server can be pinged and ui can be accessed from the internet via this IPv6). Could it be, that the "My Servers" service does not (yet) support IPv6?