Varför går filbehörigheter sönder efter att filer flyttats till en NAS?

Filer kan fungera normalt på en dator, extern enhet eller nedladdningsmapp och sedan bli skrivskyddade, osynliga för en app eller otillgängliga efter att de flyttats till en NAS. Det betyder vanligtvis inte att filinformationen är skadad. Det betyder att filerna har hamnat i ett nytt filsystem med en annan ägarskaps- och behörighetsmodell.

En flytt mellan enheter utförs ofta som en kopiering följt av borttagning av källan. NAS:en skapar nya filer med den anslutna SMB- eller NFS-identiteten, destinationsmappens ACL:er, UID- och GID-värden, umask, containeranvändare och serverbaserade skapanderegler. Det snabbaste sättet att lösa problemet är att identifiera vem som skapade filerna, vem som äger dem nu och vilken användare eller process som nekas åtkomst.

Att flytta filer till en NAS skapar vanligtvis nya filer

Att dra en mapp till en NAS kan se ut som en vanlig flytt i Windows Explorer eller Finder. Under ytan är dock källdisken och NAS separata filsystem. Klienten läser originaldata, skapar nya destinationsobjekt och tar bort originalen efter att överföringen lyckats.

Detta skiljer sig från att flytta en fil mellan två mappar på samma filsystem, där systemet vanligtvis bara uppdaterar filens katalogplats. Microsofts beskrivning av kopierings- och flyttbeteende förklarar att objekt kopierade till en annan volym ärver behörigheterna från den nya mappen, medan en flytt inom samma volym normalt behåller befintliga behörigheter.

Den skillnaden förklarar varför ”Klipp ut och klistra in” inte garanterar att ägarskap, ACL-poster eller utökade attribut förblir identiska efter en överföring till en NAS. Destinationssystemet flyttar inte bara det ursprungliga filsystemobjektet.

Destinationens ACL:er bestämmer vad nya filer ärver

Om varje nykopierad fil får samma oväntade behörigheter är vanligtvis den överordnade katalogen viktigare än källfilen. Destinationen kan ha ärvda ACL-poster, standard POSIX ACL:er, NFSv4 ACL-flaggor eller NAS-specifika behörighetsinställningar.

Till exempel kan en delad mapp konfigureras så att nya filer ärver åtkomst för en familjegrupp, en mediagrupp eller ett särskilt SMB-konto. En saknad arvflagga kan ge motsatt resultat: användare kan komma åt datasetets rot men inte nya filer inuti det.

TrueNAS-stilens behörighetssystem skiljer på POSIX och NFSv4/SMB ACL-modeller. Det viktiga är att NFSv4 och SMB ACL-arv kan styra nya filer och mappar, medan POSIX-standarder och datasetgränser beter sig annorlunda. Innan du ändrar enskilda filer, inspektera ACL och arvflaggor på destinationsmappen.

NAS använder det anslutna SMB-kontot

När en Windows- eller macOS-dator kopierar en fil över SMB bevarar NAS normalt inte klientdatorns lokala användaridentitet. Den skapar destinationsfilen som det konto som autentiserats till SMB-delningen, eller som ett konto som den sessionen är kopplad till.

Detta är anledningen till att en fil som ägs av en Windows-användare på käll-PC:n kan ägas av kenneth, nasuser, gäst, eller en annan NAS-sida identitet efter överföringen. En sparad SMB-autentisering kan också göra att en dator skapar filer under en annan ägare än en annan dator.

Kontrollera den aktiva SMB-användarnamnet istället för att anta att skrivbordsinloggningen används. Koppla bort delningen, rensa gamla autentiseringsuppgifter vid behov och anslut igen med det NAS-konto som ska äga eller hantera filerna.

Delningsåtkomst och filåtkomst är separata behörighetslager

En användare kan öppna SMB-delningen och bläddra i mappar men ändå inte kunna redigera, byta namn på eller ta bort en fil. Det betyder att nätverksdelningen är nåbar; det bevisar inte att filsystemet har beviljat den begärda åtgärden.

Regler på delningsnivå avgör om en SMB- eller NFS-klient får åtkomst till delningen och om anslutningen presenteras som skrivskyddad eller läs/skriv. Det underliggande filsystemet utvärderar sedan ägare, grupp, mode-bitar, ACL-poster och arvregler för varje fil och katalog.

Felsök båda lagren. En delning markerad som läs/skriv kan inte åsidosätta en filsystem-ACL som nekar skrivning, och tillåtande filsystemslägen hjälper inte när SMB-kontot är begränsat av delningskonfigurationen.

Windows-stil ACL:er och POSIX-mode stämmer inte perfekt överens

Windows-behörigheter kan innehålla flera användare och grupper, uttryckliga tillåt- och nekande poster, arvflaggor och separata rättigheter för läsning, skrivning, radering och modifiering. Traditionella POSIX mode-bitar reducerar åtkomst till ägare, grupp och andra.

Samba och NAS-operativsystem måste översätta mellan dessa modeller. En Windows Security-panel kan visa en detaljerad ACL även om ls -l visar endast en förenklad representation. Omvänt, att köra chmod kan ändra mode-bitar utan att korrekt återskapa den Windows-stil ACL som SMB-klienter förväntar sig.

Om NAS-datasetet använder NFSv4 eller SMB ACL:er, inspektera hela ACL via NAS-gränssnittet eller ett ACL-medvetet kommando. Anta inte att en fil som visar rwxrwx--- berättar hela behörighetshistorien.

UID- och GID-mismatch påverkar Linux, NFS och appar

Linux-system bestämmer vanligtvis ägarskap genom numeriska användar-ID och grupp-ID. Användarnamnet är bara en etikett kopplad till dessa nummer.

Två system kan båda visa en användare som heter media medan den ena använder UID 1000 och den andra UID 1001. För Linux och NFS är det olika identiteter. En fil som ägs av UID 1000 kan vara otillgänglig för en applikation som körs som UID 1001 även om deras synliga användarnamn ser identiska ut.

Kontrollera numeriska värden på NAS, värd, klient och applikation:

id media
ls -ln /path/to/files
stat /path/to/files/example.mkv

Jämför siffrorna snarare än bara de visade namnen. Om flera system behöver skriva till samma lagring, anpassa de nödvändiga UID/GID-värdena eller skapa en delad grupp med rätt behörigheter.

SMB och NFS kan skriva samma dataset som olika användare

Behörighetsproblem uppstår ofta gradvis när SMB-klienter och NFS-klienter båda har skrivåtkomst till samma katalog. Filer som laddas upp via SMB kan tillhöra en NAS-användare, medan filer som skapas via NFS kan ha ett numeriskt UID från ett annat system.

De två protokollen kan också tillämpa olika ACL- och identitetsmappningsregler. Som ett resultat kan en mapp innehålla filer som ser identiska ut för en användare men har olika ägare, grupper, masker eller ärvda poster.

Välj en primär skrivprotokoll när det är möjligt. När SMB och NFS måste dela en dataset, anpassa numeriska ID:n, delade grupper, standard-ACL:er, umask-värden och skapandebeteende innan produktionsdata placeras i den.

Docker-containrar lägger till en annan användaridentitet

En fil kan vara läsbar via SMB men otillgänglig för Plex, Jellyfin, Nextcloud, en nedladdare eller en backup-container. Docker kan montera rätt sökväg medan processen inuti containern fortfarande saknar behörighet att läsa eller skriva till den.

En containerprocess körs under en egen UID och GID. Om den identiteten inte matchar ägaren eller en tillåten grupp på den monterade NAS-sökvägen får applikationen Behörighet nekad. En volymmontering gör katalogen synlig; den kringgår inte filsystemets behörigheter.

En vanlig lösning är att matcha container-UID och GID med identiteten som har rätt att använda den monterade volymen. Verifiera den faktiska processidentiteten istället för att bara förlita dig på ett PUID- eller PGID-fält som visas i en Compose-fil:

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "Skrivbar"

En container kan skapa filer som en annan inte kan läsa

Detta händer ofta i medieautomationsstackar. En nedladdningscontainer skriver framgångsrikt en färdig fil, men mediaservern kan inte skanna den, eller en organisatör kan inte byta namn på den.

Applikationerna kan använda olika UID/GID-värden eller olika umasker. Om nedladdaren skapar filer som 600, endast dess ägare kan läsa och skriva dem. Ett läge som 640 tillåter gruppläsning, men bara när båda applikationerna delar rätt grupp.

För delade applikationskataloger, använd en planerad ägargrupp, lägg till nödvändiga applikationsidentiteter i den gruppen och välj en umask som ger gruppen den nödvändiga åtkomsten. Att bara fixa gamla filer hjälper inte om nedladdaren fortsätter skapa nya filer med restriktiva lägen.

Umask och serverns skapelseregler styr nya behörigheter

Om gamla filer fungerar men varje ny fil är otillgänglig är skapelseprocessen sannolikt orsaken. Varje program börjar med ett begärt filläge, och dess umask tar bort valda behörigheter innan filen skapas.

Samba kan också använda inställningar som skaparmask, katalogmask, tvinga användare, eller tvinga grupp. NAS-gränssnitt kan dölja dessa bakom behörighetsmallar, förinställningar för delade mappar eller arv-alternativ.

Skapa en testfil via varje väg: Windows SMB, macOS SMB, NAS filhanterare, NFS och varje relevant container. Jämför den resulterande ägaren, gruppen, läget och ACL. Detta avslöjar snabbt vilken skapelseväg som ger felaktiga behörigheter.

Olika överföringsverktyg bevarar olika metadata

Finder, Windows Explorer, ett NAS-webbgränssnitt, cp, och rsync garanterar inte identiska resultat. Vissa bevarar tidsstämplar, andra kan behålla POSIX-lägen, och ytterligare andra skapar helt enkelt nya filer enligt destinationsregler.

Innan du väljer en migrationsmetod, bestäm vilka egenskaper som måste bevaras:

• Filinnehåll och katalogstruktur
• Ändringstider
• POSIX-behörigheter
• Ägare och grupp
• ACL-poster
• Utökade attribut
• Symboliska länkar

För vanliga familjedokument eller mediefiler kan arv från destinationen vara att föredra framför att bevara källans datoranvändarkonton som inte finns på NAS:en. För applikationsdata, Linux-hemmakataloger eller servermigreringar kan det vara avgörande att bevara ägarskap och ACL-metadata.

Rsync bevarar inte alla attribut med ett grundläggande kommando

Rsync är användbart för kontrollerade NAS-migreringar, men resultatet beror på dess alternativ, privilegierna hos den användare som kör kommandot och kapaciteterna hos käll- och målfilsystemen.

Arkivläge bevarar vanlig metadata inklusive lägen, tidsstämplar, grupper och ägarskap där det är tillåtet. Ytterligare alternativ krävs när migreringen måste bevara behörigheter, ACL:er och utökade attribut med rsync. Ett typiskt Linux-till-Linux-test kan använda:

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

The -A alternativet bevarar ACL:er och -X bevarar utökade attribut när båda sidor stöder dem. --numeric-ids bör användas medvetet eftersom bevarande av en numerisk ägare som inte har något giltigt konto på NAS kan återskapa just den mismatch du försöker undvika.

En SMB-monterad rsync-destination beter sig kanske inte som NAS-filsystemet

Att köra rsync från en dator till en lokalt monterad SMB-delning är inte alltid likvärdigt med att köra rsync över SSH direkt mot NAS-filsystemet. SMB-lagret kan mappa ägare, transformera ACL:er eller avvisa försök att ställa in attribut.

Användaren som utför SMB-kopieringen kan sakna behörighet att tilldela godtyckligt ägarskap, även när rsync begär det. Mål-filsystemet kan också stödja en annan ACL-modell än källan.

Testa först en liten representativ katalog. Undersök filerna direkt på NAS efter överföringen, inte bara via klientens monterade delning. Bekräfta ägarskap, lägen, ACL:er, utökade attribut och applikationsåtkomst innan hela datasetet migreras.

NAS-behörighetsförinställningar kan åsidosätta enkla lägesbitar

Vissa NAS-system hanterar åtkomst genom dataset-ACL-mallar och utökad metadata snarare än bara traditionella ägare/grupp/andra-lägen. Detta kan göra en manuell chmod kan verka lyckat medan SMB eller en applikation fortsätter att neka åtkomst.

Ett dataset kan också vara konfigurerat för att återapplicera ärvda regler när nya filer skapas eller när behörigheter redigeras via administrationsgränssnittet. Att blanda GUI-hanterade ACL:er med upprepade kommandoradsändringar kan skapa ett inkonsekvent tillstånd.

Välj en behörighetsmodell och hantera den konsekvent. Om datasetet är konfigurerat för en SMB/NFSv4 ACL, använd NAS ACL-redigeraren eller ACL-medvetna verktyg istället för att upprepade gånger ersätta strukturen med POSIX-lägeskommandon.

Att installera om NAS återställer inte nödvändigtvis databehörigheter

Behörigheter tillhör vanligtvis filerna och filsystemdatasetet, inte bara NAS-operativsystemets konfiguration. Att installera om boot-systemet kan därför lämna samma otillgängliga ägarskap och ACL-poster på en importerad lagringspool.

Ett TrueNAS-communityfall visar hur filsystembehörigheter förblir kopplade till lagringspoolen och måste matchas med rätt användare och åtkomstkonfiguration. Det visar också risken med att göra stora rekursiva ändringar utan att först förstå den avsedda identitetsmodellen.

Innan du installerar om eller bygger om tjänster, inspektera datasetets ägare, grupp, ACL och applikationsanvändare. Data kan vara intakta och bara kräva att dess åtkomstregler återställs korrekt.

Varför rekursiv chmod 777 inte är en riktig lösning

När tusentals filer blir otillgängliga, chmod -R 777 ser ut som ett snabbt sätt att återställa åtkomst. Det ger läs-, skriv- och körbehörighet till ägare, grupp och alla andra lokala identiteter.

Det kan exponera privata data, tillåta orelaterade tjänster att ändra filer, sätta körbehörighet på vanliga dokument och skada en noggrant ärvd ACL-struktur. Det korrigerar inte heller fel ägare, missanpassad container-UID, saknad gruppmedlemskap eller trasig SMB-identitetskarta.

Använd istället den avsedda åtkomstmodellen: fastställ rätt ägare och delad grupp, bygg om lämplig ACL, ställ in katalog- och fillägen separat och korrigera framtida arv och umask-inställningar. Testa på en liten mapp innan du tillämpar rekursiva ändringar.

Reparera behörigheter från identiteten och utåt

Börja med den nekade användaren eller processen snarare än kommandot du hoppas ska lösa det. En mänsklig SMB-användare, en mediaserver och en backupcontainer kan kräva olika åtkomstnivåer.

För varje påverkade arbetsflöde, dokumentera:

• Användaren eller processen som försöker få åtkomst
• Dess numeriska UID och GID där det är tillämpligt
• Det protokoll eller monteringsläge som används
• Filens nuvarande ägare och grupp
• Den kompletta ACL och ärvda poster
• Den faktiska åtkomst som krävs: läsa, skapa, ändra eller ta bort

Modifiera sedan endast det lager som är felaktigt. Lägg till användaren i en tillåten grupp, korrigera ägarskap, reparera ACL, anpassa en container-UID eller uppdatera skapelseregeln. Undvik att ge bredare åtkomst än vad arbetsflödet behöver.

Följ en lagerindelad felsökningsordning

Att ändra delningens ACL, containeridentitet, NFS-export och fillägen samtidigt förstör användbar bevisning. Testa ett behörighetslager i taget.

Börja med en påverkad fil och en påverkad användare eller applikation. När det lilla fallet fungerar, skapa en ny fil via normal arbetsflöde och bekräfta att åtgärden också förhindrar att problemet återkommer.

Förebygg behörighetsproblem före en stor NAS-migrering

Att reparera behörigheter över hundratusentals filer är mycket svårare än att testa åtkomstmodellen före migrering. Bygg en liten målmapp med samma ACL och applikationskonfiguration som planeras för den slutgiltiga datasetet.

Kopiera flera filtyper, inbäddade kataloger, skrivskyddade filer, körbara skript och filer med utökade attribut. Testa dem från varje nödvändig väg: SMB, NFS, NAS-gränssnittet, backup-programvara och relevanta containrar.

Börja endast fullständig migrering när nya filer konsekvent får rätt ägare, grupp, ACL och applikationsåtkomst. Behåll en snapshot eller backup innan du tillämpar några rekursiva ägarskaps- eller behörighetsändringar på befintliga data.

Slutsats

Filsbehörigheter går sönder efter att data flyttats till en NAS eftersom överföringen vanligtvis skapar nya filsystemobjekt. Dessa objekt styrs av NAS-kontot som används för överföringen, målets ACL, UID/GID-värden, umask, protokollkartläggning och applikations- eller containeridentitet.

Börja inte med chmod 777. Svara först på tre frågor: vem skapade filen, vem äger den nu och vilken identitet nekas åtkomst. Inspektera sedan delningsåtkomst, filsystemets ACL:er, ärvning, container-ID:n och framtida skapanderegler.

En lyckad reparation bör göra två saker: återställa lämplig åtkomst till befintliga filer och säkerställa att nästa fil som kopieras, laddas ner eller skapas på NAS automatiskt får rätt behörigheter.

FAQ

Varför ärver kopierade filer NAS-mappens behörigheter?

En överföring till en NAS skapar vanligtvis nya filer på ett annat filsystem. Nya objekt tilldelas ofta behörigheter från målmappens ACL, ärvflaggor och serverbaserade skapanderegler.

Varför kan jag öppna NAS-filer över SMB men min Docker-container kan inte?

SMB-sessionen och containern använder olika identiteter. Kontrollera containerns faktiska UID och GID, den monterade sökvägens numeriska ägarskap, gruppmedlemskap och om monteringen är skrivskyddad.

Ska jag använda chmod 777 för att reparera en NAS-delning?

Nej. Det ger varje lokal identitet bred åtkomst, kan skada ACL-ärvning och löser inte felaktigt ägarskap eller UID/GID-kartläggning. Definiera de avsedda användarna och grupperna, och reparera sedan ägarskap och ACL:er därefter.

Kan rsync bevara NAS-filsbehörigheter?

Den kan bevara POSIX-behörigheter och annan metadata när de valda alternativen, exekveringsrättigheterna och båda filsystemen stödjer dem. ACL:er och utökade attribut kräver ytterligare alternativ som till exempel -A och -X.

Varför fortsätter nya filer att gå sönder efter att jag har reparerat de gamla filerna?

Skapelsevägen är fortfarande fel. Kontrollera den ärvda ACL för målmappen, SMB- eller NFS-identiteten, applikationens umask, Sambas skapanderegler och container-UID/GID.