Joakim Melin
Ytterligare äventyr med Unraid ⚓
Min installation av Unraid har tuffat på i snart en månad utan större missöden. Det finns givetvis saker som kunde varit bättre, som exempelvis det faktum att om man vill ta bort en hårddisk ur systemet utan att ersätta den med en annan (rekommenderas inte om du saknar en paritetsdisk) så måste man blåsa hela konfigurationen och börja om från början igen med att mappa upp vilka diskar som gör vad. Lite bökigt men det går att leva med.
En sak som däremot har retat mig enormt är den oerhört usla skrivprestandan över SMB-protokollet från min Mac. Ja, det är sannolikt Apple och macOS som är skurken i detta lilla drama och inte Unraid, men jag satte mig ned och började pilla med det och efter en del testande (och sökande på interwebzen) så har jag en konfiguration som erbjuder betydligt bättre prestanda än tidigare.
Det första du ska göra är att stoppa din array. Därefter går du in i Settings -> SMB
och i fältet för SMB EXTRAS
klistrar du in följande:
aio read size = 1
aio write size = 1
strict locking = No
use sendfile = No
server multi channel support = Yes
readdir_attr:aapl_rsize = no
readdir_attr:aapl_finder_info = no
readdir_attr:aapl_max_access = no
fruit:posix_rename = yes
fruit:metadata = stream
Gränssnittet kan lura dig i att tro att du endast kan lägga in en rad där men det går att pejsta in flera.
Därefter skapar du en fil på din Mac (jag kör macOS v14.1.2 “Sonoma” när detta skrivs) vid namn /etc/nsmb.conf
(görs med exempelvis sudo nano /etc/nsmb.conf
) och häller in följande:
# /etc/nsmb.conf - macOS 11.3+
#-----------------------------------------------------------------------------
# Additional information:
# -----------------------
# https://support.apple.com/de-de/HT211927
# https://support.apple.com/en-us/HT208209
# https://apple.stackexchange.com/questions/309016/smb-share-deadlocks-since-high-sierra
# https://photographylife.com/afp-vs-nfs-vs-smb-performance
# https://support.apple.com/de-de/HT212277
# https://www.synoforum.com/threads/mac-clients-smb-cache-issues.7009/page-3
# UnRaid SMB extra configurations:
# https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X
# https://www.samba.org/samba/docs/current/man-html/vfs_fruit.8.html
#
# To speed up SMB file browsing, you can prevent macOS from reading .DS_Store files on
# SMB shares. This makes the Finder use only basic information to immediately display
# each folder's contents in alphanumeric order.
# defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
# log out of your macOS account and log back in to apply
#------------------------------------------------------------------------------
# Use NTFS streams if supported (Macs use two streams per file - ADS or "multi-fork")
streams=yes
# Set hard or soft mount of shares
# Hard mount: a request is issued repeatedly until the request is satisfied
# Soft mount: tried until completed, the retry limit is met or the timeout limit is met
# Soft mount by default
soft=yes
# Disable packet signing to improve performance as no security issue on secure (non-infiltrated) network.
# Note this is off by default from macOS 10.13.4 onwards although this is ambiguous (Apple HT205926)
signing_required=no
# Disable directory caching (ensures Finder folder contents display is up to date)
dir_cache_off=yes
# Disable local SMB caching
# Can be set and then unset to clear SMB cache
dir_cache_max_cnt=0
# Ensure desired SMB level and prevent SMB 1 (Apple HT211927)
# Lock negotiation to SMB2/3 only
# 7 == 0111 SMB 1/2/3 should be enabled
# 6 == 0110 SMB 2/3 should be enabled
# 4 == 0100 SMB 3 should be enabled
protocol_vers_map=6
# No SMB1 = no NetBIOS (WINS) and it should be disabled
port445=no_netbios
# Turn off change notifications (Finder maintains folder list integrity)
# notify_off=yes
# SMB Multichannel behaviour (Apple HT212277)
# Disable multichannel support because only one wired network connection
mc_on=yes
# Prefer wired networks over Wi-Fi networks that may advertise faster speeds than appropriate
mc_prefer_wired=yes
Du behöver logga ut från ditt konto på din Mac och logga in igen för att inställningarna ska aktiveras.
Det var väl det hela. Det har hjälpt för mig och hoppas det gör det för dig också!
Vidare äventyr med Unraid ⚓
Efter min lyckade och samtidigt misslyckade första installation av Unraid så rev jag hela systemet, stoppade i ytterligare tre SSD-diskar och satte sedan igång med att bygga min array på rätt sätt. Det rätta sättet var enligt vad jag kunde läsa mig till detta: ZFS eller btrfs för array:en där datat lagras, ZFS för den eller de diskar man vill använda som cache och paritetsdisken ska vara en SSD-disk som är minst lika stor som den största disken i din array. Så jag tänkte att ZFS är väl en bra väg att gå och satte därmed igång med att bygga det hela.
Unraid är hyfsat ologiskt när det gäller att bygga en array, i synnerhet när det gäller just vilket filsystem man ska välja. Man kan välja att lägga till diskarna till en array och startar man sedan denna array så väljer Unraid själv vilket filsystem som körs, vilket i praktiken innebär XFS som vad jag förstår närmast är standard i Unraid.
Man måste därför klicka in sig på varje disk och sätta ZFS som filsystem. Inte helt logiskt som sagt men när man väl vet det så är det ingen ko på isen direkt.
Unraids implementation av ZFS är inte mer logisk. I Freenas man kan sätta cache och logg-diskar för en volym men i Unraid så kan man välja en cachedisk och sedan en paritetsdisk. Vad man ska med en paritetsdisk till när man samtidigt har valt raid-z 1 eller 2 som uppsättning för ZFS, vilket alltså innebär att man kan tappa en eller två diskar i sin volym utan att förlora data, är för mig obegripligt.
Men låt gå då - jag satte upp det hela enligt den modellen: ZFS med raid-z 1 och en paritetsdisk och sedan formatterades diskarna och pang så var det klart. Två saker noterade jag omedelbart: ZFS åt upp i princip allt av de 20 gigabyte internminne som sitter i NAS-datorn (kanske inte helt oväntat men Freenas har ett bra sätt att balansera det där - Unraid verkar inte besitta samma egenskaper), och min NAS-dator gick oerhört långsamt. Kanske hade det gått snabbare med en cachedisk men på något sätt är jag en aning skeptisk till det, utan att kunna ta på varför.
Jag satte därefter igång med att tanka över de över två terabyte data som ska lagras på den och noterade snart att den hade problem med vissa filnamn, prestanda och… vips så kraschade Unraid.
Så jag började läsa på ännu mer. Efter ett par timmars studerande och funderande så kom jag fram till följande konfiguration: sex stycken 1TB SSD-diskar i min array, en 1TB SSD-disk för paritet och 500 gigabyte SSD-disk för cache. Jag satte cachedisken till ZFS och arraydiskarna till XFS.
Efter att jag byggt upp denna konfiguration så formligen flyger lagringen fram. Dock kan man bli lite smått ledsen på tiden det tar att bygga en ny paritetsdisk men det är knappast Unraids fel.
Inga krascher har inträffat och de Docker-baserade applikationer jag installerat fungerar också utmärkt. Här skiljer sig Unraid väldigt mycket mot exempelvis Truenas. Kanske är det en indikation på att Unraid främst vänder sig till hobbyister och hemanvändare medan Truenas siktar lite högre upp i “näringskedjan” för i Unraid så finns det i princip allt i form av “plugins” som körs som kontainrar under Docker. Man kan också köra virtuella maskiner under Unraid (jag har inte testat det ännu men gissar att det baseras på Qemu eller liknande då virtio-drivrutiner ska användas för Windows-baserade virtuella maskiner).
Jag får acceptera att jag inte har TRIM-stöd för mina SSD:er när jag använder XFS, men med tanke på hur billigt det är med SSD-diskar på en terabyte nu för tiden kan jag nog leva med det.
När detta skrivs är det drygt två dygn kvar på Unraids “Cyber Weekend Sale” där de erbjuder 10 procents rabatt på alla licenser. Unraid är till skillnad mot Truenas inte gratis utan kostar pengar men det är en engångskostnad och man kan provköra Unraid utan att betala i åtminstone en månad utan problem så är du nyfiken rekommenderar jag att du tar en titt.
Äventyr med Unraid ⚓
Efter att ha använt Truenas i närmare ett år så kom jag till ett par slutsatser. Det första är att jag blivit galet trött på att lyssna på fyra stycken 4TB-diskar snurra och knattra. Det andra är att äldre hårddiskar, som de nyss nämnda 4TB-diskarna, inte är en bra ide att köra med Truenas och ZFS då det verkar ta livet av dem i en hyfsat hög hastighet. Låt vara att detta var gamla Seagate “Enterprise”-diskar på 4TB vardera som redan hade ett antal år på nacken, men under det dryga året jag kört denna lösning så har jag fått kasta fyra diskar som packat ihop.
Detta kombinerat med att jag var nyfiken på en annan lösning gjorde att jag grävde djupt i plånboken, köpte mig ytterligare ett antal SSD-diskar och smackade ihop en “ny” maskin med åtta 1TB SSD-diskar, 20GB RAM och en AMD Ryzen 5 2400G-processor som numera kör Unraid.
Resan var dock inte helt smärtfri för att komma dit.
När jag började bygga min Unraid-maskin hade jag nämligen bara fyra SSD-diskar. Eftersom jag gjorde som jag brukar göra så läste jag givetvis ingen dokumentation utan laddade ned verktyget för att skapa en USB-sticka för Unraid och sen satte jag igång.
Unraid skiljer sig nämligen från Truenas på många sätt, och ett av dessa är att Unraid inte går att installera på en hårddisk. Det är byggt för att boota från en USB-sticka. Det är ju inget problem om man väljer en bra USB-sticka som inte redan har raderats 511 gånger (jag kommer till det senare). Tanken med USB-stickan är inte så dum som den kan låta - eftersom man betalar för Unraid så kan man också lätt flytta systemet med USB-stickan till en annan maskin om man vill använda systemet där istället.
Jag satte igång att skapa en array baserad på filsystemet XFS. Det verkade som standardinstallationen så jag valde det och vips så hade jag en array på 4TB (4 x 1TB SSD). Detta var mitt första misstag.
Mitt andra misstag var jag inte läste på om behovet av en paritetsdisk. Eftersom XFS inte är ett RAID-system, eller på något sätt erbjuder någon form av redudans utan just en paritetsdisk, så är det sistnämnda inte ett önskemål, det är ett krav.
Mitt tredje misstag var att välja just XFS. Unraid gör en stor affär av att man kan putta i vilka hårddiskar man vill i sitt system och vips så har man en NAS. Det är förvisso sant, men om man väljer XFS kan man i efterhand inte expandera sin array. Unraid skriver själva på sin blogg att det bara är att expandera, men det är i mitt tycke en aning luddigt:
“Unraid’s native XFS or BTRFS file systems deliver good read speeds for most media server users.
The array is readily expandable (an essential consideration for you media data hoarders out there as your collections grow!)”
Detta faktum upptäckte jag efter att jag köpt ytterligare tre SSD-diskar på 1TB vardera, tre för data och en för paritet.
Mitt fjärde misstag var samma som mitt tredje: att välja XFS. Unraid är nämligen egentligen byggt för att använda sig av vanliga hårddiskar. Man kan, om man kör XFS, använda SSD:er för cache, men det är inte rekommenderat att man bygger en vanlig array baserad på XFS om man använder enbart SSD:er. Detta beror på att Unraid inte stödjer TRIM när man använder XFS (använder man btrfs eller zfs så är detta inte ett problem). Har man en cachedisk inlagd i sin XFS-array så kan man köra trim på den, men inte övriga diskar i array:en.
Vad är då lösningen? Jag fick tömma hela min array på data, radera den och sedan skapa en ny array baserad på btrfs eller zfs.
Mitt femte misstag var att jag valde ett äldre USB-minne att boota från. Det är nämligen så att även om Unraid inte skriver loggar och annat till USB-minnet så lagrar den en hel del väldigt viktig information om systemet, i synnerhet information om dina diskar, din licens, din array, konfiguration, och så vidare. I mitt fall så visade sig problemet med USB-minnet inte förrän jag startade om systemet och det inte gick att starta från det längre.
Jag försökte läsa ut information från USB-minnet men partitionstabellen var rökt och de filer som jag faktiskte behövde var korrupta. Så jag fick börja om med ett nytt, i alla bemärkelser, USB-minne och koppla ur mina tre nya diskar. Efter det var det inte svårare än att lägga till de fyra diskar jag redan hade och vips så var min array tillbaka. Till och mina Docker-containrar bara fungerade utan vidare. Hade jag däremot haft en paritetsdisk och inte vetat vilken disk det var så hade jag haft betydligt större problem.
Lösningen på detta är att ta regelbunden backup på konfigurationen - det finns en funktion för detta i det för övrigt riktigt trevliga webbgränssnittet. Varför USB-minnet avled? Vem vet - det kanske inte var byggt för att vara inkopplat dygnet runt.
Detta är en första bloggpost av mina intryck av Unraid. I del två reder jag ut hur en fungerande konfiguration, med sina fördelar och nackdelar, ser ut.
Datormagazin Retro #7: boka ditt nummer idag! ⚓
Nog för att en Mac eller iPad är rolig. Eller kanske till och med en PC. Men ibland är det senaste inte riktigt vad själen behöver. Ibland behöver man få frossa i forntiden, i det som var (för allt var ju bättre förr, som alla vet). Det är för såna som dig som vi gör tidningen Datormagazin Retro och nu är det dags för vårt sjunde nummer!
Som vanligt kommer tidningen vara fullpackad med intressant och rolig läsning, och här är några artikelideér vi surrat om under planeringen:
- Historien om Dune 2
- Vi besöker Embracer Games Archive
- Programmera mera på C128
- Världens mest sällsynta Amiga
- Giana Sisters vs. Super Mario Bros
- Demodags
- Backchat med Brad S
- Expertens bästa tips
- … och mycket mer
Glid över till Datormagazin Retros kampanjsajt omedelbums och spana in de fina paketen som erbjuds. Ju snabbare vi har 1000 förbeställningar, desto snabbare kommer tidningen levereras.
Cloudflare-tunnel och Wordpress ⚓
Då jag kör alla mina webbsajter, och även poddens dito, via tunnlar hos Cloudflare så är det givetvis så att saker och ting är en aning annorlunda jämfört med att köra sajten “naket” direkt mot Internet. Cloudflares tunnel fungerar som en proxy som routar trafiken via Cloudflare och i Cloudflares proxy termineras även SSL-certifikaten för webbsajterna, med mera.
Detta fungerar utan några som helst problem för sajter som denna, men för Wordpress är det annorlunda. Wordpress är, och har alltid varit, ganska uselt på att hantera SSL. En värre blir det när man ställer en webbsajt baserad på Wordpress bakom en proxy, i det här fallet tunneln via Cloudflare. Jag lyckades till slut få det att fungera när jag gjorde hela flytten till egen server hos Hetzner i somras men då jag var tvungen att rota runt lite i konfigurationen idag, och givetvis hade sönder allt eftersom jag inte mindes hur jag löst det, så bestämde jag mig för att dokumentera det för mig själv och för andra som funderar på att göra samma lösning.
Varför ska man titta på en tunnel hos Cloudflare, kanske du undrar? Om du kör en server hemma och inkommande trafik är spärrad, eller om din internetleverantör använder sig av det som kallas för Carrier-grade NAT, eller CGNAT (för att ta två exempel), så kan en gratis tunnel hos Cloudflare göra att du faktiskt kan köra din webbsajt hemma ändå.
Wordpress och Cloudflare-tunnel
När man sätter upp sin tunnel mellan Cloudflare och sin egna server så finns det ingen anledning att skicka trafiken över https (kryptering medelst SSL)-protokollet då trafiken mellan Cloudflare och din server går i en krypterad tunnel. Alltså gör man det enkelt för sig och låter webbservern hemma prata http, utan något SSL-certifikat. När man installerat sin Wordpress-sajt och fått igång tunneln mellan servern och Cloudflare kommer man upptäcka att sajten fungerar fin-fint när man besöker den, men när man går in i inställningarna och vill ändra sajtens adress till https://www.dinsajt.tld
så brakar det. Du kan inte logga in administrationsgränssnittet och ställa tillbaka webbsajtens adress till http://www.dinsajt.tld
och om du inte vill sätta igång och rota i databasen för att där ändra webbsajtens adress (den lagras i databasen, nämligen) så är läget en aning knepigt.
Sajten kommer kunna fortsätta att ta emot besök men när man vill logga in i det administrativa gränssnittet så får man det ökända felmeddelandet om “too many re-directs”. Detta beror på att Cloudflare-tunneln försöker leda om all trafik till https medan webbservern hemma är konfigurerad för att endast prata http. Detta gör att Wordpress vill prata https medan webbservern vill prata http, och sen går detta i en loop några gånger tills webbläsaren ger upp.
Lösningen är relativt enkel, och den matas in i wp-config.php
-filen där din Wordpress-konfiguration ligger.
Dessa två rader är din räddning:
define('WP_HOME','http://www.dinsajt.tld');
define('WP_SITEURL','http://www.dinsajt.tld');
Genom att ange http i dessa två rader så kommer du kunna logga in i administrationsgränssnittet igen och kunna fortsätta arbeta med din webbsajt.
Snart kommer dock ett annat problem att uppstå, och det beror på att Wordpress tror att den kommunicerar via http och inte https vilket gör att innehållet i Wordpress inte skickas enbart över https, så-kallat mixed content. Detta löser du genom att ange följande rad i wp-config.php
:
$_SERVER['HTTPS']='on';
Nu talar du om för Wordpress att den skickar ut all data via https.
Ett tredje problem kan uppstå om du installerar en plugin för exempelvis trafikanalys till din webbsajt. Du kan se felmeddelanden som detta:
Error connecting to WordPress REST API. Disable ad-blocker for this page or unblock /wp-json/wp-statistics/v2/metabox in the ad-blocker configuration.
Detta har dels med problemet ovan, mixed content, och dels med att Cloudflare har en egen brandvägg som nyper ihop så fort den misstänker att det går lite väl mycket trafik till en viss del av din webbsajt. Jättebra i normala fall men inte i detta läge.
För att komma runt detta så skapar du en regel hos Cloudflare för att slå av säkerheten för www.dinwebbsajt.tld/wp-json/*
. Mina två regler för poddens webbsajt ser ut så här:
Efter att du skapat denna regel och också lagt in ändringarna i wp-config.php
så ska din sajt fungera normalt.
© 2000 - 2025 Joakim Melin.
