Ja. Flera containrar kan binda samma dataset som skrivskyddat, medan en kontrollerad skrivare eller värdprocess ansvarar för uppdateringar.
Beslutet är viktigt när flera indexerare, medieservrar eller AI-tjänster behöver samma original utan rätt att ändra dem. De två konkurrerande tillstånden är delade skrivskyddade vyer och dolda skrivbara undermonteringar, eller en app som kräver skrivningar till sidofiler. Börja med en sparad konfiguration och data som kan slängas, observera en gren i taget och avbryt om testet ökar risken för dataförlust, behörighetsproblem eller tillgänglighetsproblem.
Definiera villkoren bakom beslutet om delade skrivskyddade datasetmonteringar
Dokumentera miljön innan du ändrar något: programvaru- och firmwareversioner, enhetsidentiteter, monterings- eller nätverkssökväg, ledigt utrymme, behörigheter och det observerbara symtomet. Baslinjen måste innehålla tillräckligt med detaljer för att återskapa att flera indexerare, medieservrar eller AI-tjänster behöver samma original utan rätt att ändra dem.
Den första kandidaten är delade skrivskyddade vyer. Den andra är dolda skrivbara undermonteringar eller en app som kräver skrivningar till sidofiler. Den aktuella skrivskyddade Compose-tjänstevolymen definierar mekanismen eller kommandogränsen som används i testet; den ersätter inte observation från just den här hemservern.
Skriv ned godkännandekriteriet och stoppkriteriet innan du kör skiljetestet. Ett godkänt resultat måste ändra de bevis som förutsägs av en gren, samtidigt som orelaterade tjänster förblir oförändrade; ett underkänt resultat måste återställa systemet till det sparade tillståndet i stället för att utlösa en kedja av spekulativa korrigeringar.
Testa påståendet utan att sänka det ursprungliga kravet
Använd detta skiljetest: inspektera de upplösta monteringarna för varje container, försök skriva till data som kan slängas och verifiera att filändringar sprids från den auktoriserade skrivaren. Håll arbetsbelastning, klient, sökväg, filuppsättning och tidsintervall konstanta så att resultatet kan hänföras till den ändrade variabeln.
Använd inspektion av skrivskyddade volymer för att välja det fält som faktiskt kan skilja grenarna åt, och fånga dess tidsstämpel, avslutsstatus, feltext, enhets- eller ögonblicksbildsidentitet, fördröjning, överförda byte, behörigheter och återställningstillstånd. Ett felfritt kommandoavslut räcker inte när identitet, beständighet eller applikationstillstånd är påståendet som testas.
Upprepa testet en gång efter en omstart, återanslutning, ny montering eller kall cache när den händelsen ingår i det ursprungliga villkoret. Om den första körningen är destruktiv eller miljön inte kan återställas, avbryt och återskapa i stället på en kopia som kan slängas.
volumes:
- /nas/media:/media:ro
- app-cache:/cache:rw
Tolka godkända, underkända och avvikande resultat
GODKÄNT: alla läsare ser uppdateringar, men skriv-, namnbytes- och raderingsåtgärder misslyckas i varje container. Dokumentera den exakta versionen, identiteten och arbetsbelastningen som godkändes så att slutsatsen förblir villkorad i stället för att bli ett universellt påstående.
UNDERKÄNT: en montering är av misstag rw, en kapslad montering kringgår policyn eller appen kan inte fungera utan närliggande skrivningar. Ett underkänt resultat bevisar inte automatiskt den motsatta grenen när nätverk, minne, behörigheter eller källans konsistens kan påverka båda; isolera dessa gemensamma beroenden innan du eskalerar.
AVVIKANDE ELLER TVETYDIGT RESULTAT: stoppa den berörda containern och separera dess skrivbara cache eller sidofiler till en annan volym. Bevara loggarna och kör inte reparations-, rensnings-, förstörings-, ompartitionerings- eller rekursiva ägarskapskommandon förrän det finns en återställningsbar kopia.
Bekräfta beslutet under den ursprungliga arbetsbelastningen
Tillämpa den åtgärd som motsvarar den observerade grenen och upprepa sedan det ursprungliga villkoret i stället för en förenklad ersättning. Beslutet gäller endast när alla läsare ser uppdateringar, men skriv-, namnbytes- och raderingsåtgärder misslyckas i varje container under två cykler eller vid relevant omstart, viloläge, avbrott eller belastningsövergång.
Använd skrivskyddade rotfilsystem för att kontrollera det närmast beroende arbetsflödet, men behåll den ursprungliga utlösaren oförändrad. Orelaterade dataset, utdelningar, containrar, användare och återställningspunkter måste behålla sin tidigare åtkomst och tidsåtgång.
Stoppgränsen är tydlig: om en montering är av misstag rw, en kapslad montering kringgår policyn eller appen inte kan fungera utan närliggande skrivningar, återgå till den senast verifierade konfigurationen, behåll bevisen och eskalera till ett djupare plattforms- eller hårdvarutest endast när grenen kan upprepas.
När målresultatet håller jämför du det med mappning av containeridentiteter så att korrigeringen inte flyttar risken till en närliggande tjänst. Ett godkänt måltest med ett nytt fel i säkerhetskopiering, identitet, tidsgräns eller tillgänglighet är fortfarande en misslyckad ändring.
Vanliga frågor
För delade skrivskyddade datasetmonteringar gäller de återstående sökningarna vanligtvis om läsare kan se ändringar som skrivaren gör, om :ro skyddar värddatasetet från root i containern och var miniatyrbilder eller databaser ska placeras. Svaren nedan håller dessa specialfall åtskilda från huvudbeslutet.
Godkännandegränsen flyttas inte: alla läsare ser uppdateringar, men skriv-, namnbytes- och raderingsåtgärder misslyckas i varje container. Om ett uppföljande villkor ändrar filsystemet, identiteten, nätverkssökvägen eller applikationsversionen upprepar du endast det skiljetest som påverkas av ändringen.
Sluta bredda experimentet när en montering är av misstag rw, en kapslad montering kringgår policyn eller appen inte kan fungera utan närliggande skrivningar. Stoppa då den berörda containern och separera dess skrivbara cache eller sidofiler till en annan volym; bevara bevisen innan du eskalerar till plattforms-, lagrings- eller hårdvaruansvarig.
Kan läsare se ändringar som skrivaren gör?
Ja, med förbehåll för applikationscache och filsystemets händelsehantering; testa uppdaterings- och namnbytesfall.
Skyddar :ro värddatasetet från root i containern?
Det gör den monteringen skrivskyddad, men bredare behörigheter eller andra monteringar kan fortfarande utöka åtkomsten.
Var ska miniatyrbilder eller databaser placeras?
Använd separata skrivbara volymer så att genererat tillstånd inte kräver skrivåtkomst till originalen.
För delade skrivskyddade datasetmonteringar är det praktiska svaret fortfarande villkorat: alla läsare ser uppdateringar, men skriv-, namnbytes- och raderingsåtgärder misslyckas i varje container. När en montering är av misstag rw, en kapslad montering kringgår policyn eller appen inte kan fungera utan närliggande skrivningar, stoppa den berörda containern och separera dess skrivbara cache eller sidofiler till en annan volym; en delvis lyckad ändring som inte överlever den ursprungliga arbetsbelastningen är inte kompatibilitet.
Support och tips
Mer att läsa

Kan ett egenhostat galleri bevara parkopplingen mellan Apple Live Photos?
Ett villkorat beslut för hemmaservern om parkoppling med Apple Live Photo, med kontrollerade tester, resultattolkning, återställning och fokuserade vanliga frågor.

Kan du importera Google Takeout och telefonbackuper till ett enda fotobibliotek?
Ett villkorat beslut för en hemmaserver för kombinerad fotoimport, med kontrollerade tester, resultattolkning, återställning och fokuserade vanliga frågor.

Kan Immich använda ett externt bibliotek utan att ta över ägandet av filerna?
Ett villkorat beslut för hemservern om ägarskap av externa bibliotek i Immich, med kontrollerade tester, resultattolkning, återställning och fokuserade vanliga frågor.

