Wanneer chown en chmod niets lijken te doen op een USB-schijf, moet je eerst het bestandssysteem identificeren. Het antwoord uit de community vermoedde NTFS of exFAT. Dat is een plausibele verklaring, omdat deze bestandssystemen zich niet gedragen zoals ext4/Btrfs, met native Unix-eigenaarschap en modusbits.
De bron vermeldt niet welk bestandssysteem MikeFrizz daadwerkelijk gebruikte, en de oorspronkelijke poster heeft nooit teruggekoppeld met een bevestigd resultaat. Daarom moet dit een bestandssysteembewuste probleemoplossingsgids blijven, en geen bewering dat elke ZimaOS-USB-schijf rechten negeert.
Identificeer het USB-bestandssysteem voordat je rechten wijzigt
Controleer de schijfindeling in ZimaOS Opslag of met een alleen-lezen opdracht zoals:
lsblk -fDe huidige versie van ZimaOS ondersteunt lees- en schrijftoegang tot onder andere NTFS, exFAT, ext4 en Btrfs, maar “lees-/schrijftoegang ondersteund” betekent niet dat alle bestandssystemen Unix-UID/GID-/modusmetadata op dezelfde manier bewaren.
Gebruik de actuele matrix met ondersteunde schijfformaten.
NTFS en exFAT tonen rechten vaak via mountopties
Op Linux tonen exFAT en veel NTFS-mountconfiguraties bestanden met eigenaars- en moduswaarden die zijn afgeleid van mountopties, in plaats van gewone POSIX-rechten exact op te slaan zoals ext4 dat doet. Daardoor kunnen chown of chmod geen effect lijken te hebben of na het opnieuw mounten worden teruggedraaid.
Dat betekent niet dat de schijf alleen-lezen of defect is.
Een Linux-bestandssysteem geeft Docker de meest voorspelbare POSIX-rechten
Als de USB-schijf uitsluitend voor ZimaOS/Linux wordt gebruikt en je echte controle over UID/GID/modus nodig hebt, zijn ext4 of Btrfs een natuurlijkere keuze. Opnieuw formatteren vernietigt gegevens, dus kopieer de data elders voordat je van bestandssysteem verandert.
Gebruik geen symbolische koppeling op de host als primaire migratiemethode voor Docker-opslag
De gebruiker uit de bron kopieerde Immich-gegevens naar USB en maakte een symbolische koppeling vanaf de oude locatie. Containers volgen symbolische koppelingen op de host buiten hun gemounte volumenaamruimte niet automatisch. De symbolische koppeling kan verwijzen naar een pad dat de container niet kan zien.
Een directe bind-mount of een rechtstreeks volume is duidelijker en eenvoudiger te controleren.
Koppel de USB-map rechtstreeks aan Immich
In plaats van een oud hostpad te behouden en dit met een symbolische koppeling om te leiden, bewerk je het volume van de Immich-app/container zodat de echte USB-map wordt aangekoppeld op het containerpad dat Immich verwacht.
De huidige documentatie van IceWhale legt uit dat het hostpad kan worden gewijzigd zonder het pad aan de containerzijde te wijzigen.
Gebruik het actuele ZimaOS-model voor Docker-volumepaden.
Verplaats niet blindelings elk Immich-onderdeel naar willekeurige USB-opslag
Immich-mediabibliotheken en uploadopslag hebben andere vereisten dan de PostgreSQL-database en applicatiestatus. Bepaal voordat je mappen verplaatst precies welk hostvolume wordt verplaatst en volg de actuele implementatie- en migratierichtlijnen van Immich.
Verplaats geen actieve databasemap met een symbolische koppeling terwijl de containers actief zijn.
Herstel eerst de koppeling voordat je breedweg chmod 777 gebruikt
Als de container de juiste hostmap niet kan zien, lossen gewijzigde rechten het padprobleem niet op. Controleer eerst de mount en pas daarna alleen de minimale gebruikers- en groepsrechten aan die de container nodig heeft.
Veelgestelde vragen over USB-rechten
Ondersteunt ZimaOS lezen en schrijven naar NTFS en exFAT?
Ja, de huidige documentatie van IceWhale vermeldt dat beide lees- en schrijfmogelijkheden ondersteunen.
Waarom kunnen chmod en chown zich dan toch anders gedragen?
Deze bestandssystemen gebruiken native Linux-POSIX-semantiek voor eigenaarschap en modi niet op dezelfde manier als ext4 of Btrfs.
Zijn het bestandssysteem van de gebruiker uit de bron en de uiteindelijke oplossing bevestigd?
Nee. Het bestandssysteem werd door een communityreactie afgeleid en de oorspronkelijke poster heeft geen resultaat gemeld.
