Waarom breken bestandsrechten na het verplaatsen van bestanden naar een NAS?

Bestanden kunnen normaal werken op een computer, externe schijf of downloadmap en daarna alleen-lezen, onzichtbaar voor een app of ontoegankelijk worden nadat ze naar een NAS zijn verplaatst. Dat betekent meestal niet dat de bestandsdata beschadigd is. Het betekent dat de bestanden een nieuw bestandssysteem zijn binnengegaan met een ander eigendoms- en machtigingsmodel.

Een verplaatsing tussen apparaten wordt meestal uitgevoerd als een kopie gevolgd door het verwijderen van de bron. De NAS maakt nieuwe bestanden aan met behulp van de verbonden SMB- of NFS-identiteit, ACL's van de doelmap, UID- en GID-waarden, umask, containergebruiker en server-side aanmaakregels. De snelste manier om het probleem op te lossen is te achterhalen wie de bestanden heeft gemaakt, wie ze nu bezit en welke gebruiker of proces wordt geweigerd.

Bestanden verplaatsen naar een NAS maakt meestal nieuwe bestanden aan

Het slepen van een map naar een NAS lijkt in Windows Verkenner of Finder op een gewone verplaatsing. Onder de motorkap zijn de bron-schijf en NAS echter aparte bestandssystemen. De client leest de originele data, maakt nieuwe bestemmingsobjecten aan en verwijdert de originelen nadat de overdracht is geslaagd.

Dit verschilt van het verplaatsen van een bestand tussen twee mappen op hetzelfde bestandssysteem, waarbij het systeem mogelijk alleen de bestandslocatie bijwerkt. Microsoft’s beschrijving van kopieer- en verplaatsgedrag legt uit dat objecten die naar een ander volume worden gekopieerd de machtigingen van de nieuwe map erven, terwijl een verplaatsing binnen hetzelfde volume normaal gesproken de bestaande machtigingen behoudt.

Dat onderscheid verklaart waarom “Knippen en Plakken” niet garandeert dat eigendom, ACL-vermeldingen of uitgebreide attributen identiek blijven na een overdracht naar een NAS. Het bestemmingssysteem verplaatst het oorspronkelijke bestandssysteemobject niet simpelweg.

Bestemmings-ACL's bepalen wat nieuwe bestanden erven

Als elk nieuw gekopieerd bestand dezelfde onverwachte machtigingen krijgt, is de bovenliggende map meestal belangrijker dan het bronbestand. De bestemming kan geërfde ACL-vermeldingen, standaard POSIX-ACL's, NFSv4-ACL-vlaggen of NAS-specifieke machtigingsinstellingen hebben.

Een gedeelde map kan bijvoorbeeld zo worden geconfigureerd dat nieuwe bestanden de toegang erven voor een familie-, media- of een specifieke SMB-groep. Een ontbrekende erfenisvlag kan het tegenovergestelde resultaat creëren: gebruikers kunnen toegang hebben tot de dataset-root, maar niet tot nieuwe bestanden daarin.

TrueNAS-stijl permissiesystemen onderscheiden POSIX- en NFSv4/SMB-ACL-modellen. Het belangrijke gedrag is dat NFSv4- en SMB-ACL-overerving nieuwe bestanden en mappen kan controleren, terwijl POSIX-standaarden en datasetgrenzen anders werken. Controleer vóór het wijzigen van individuele bestanden de ACL en overervingsvlaggen op de doelmap.

De NAS gebruikt het verbonden SMB-account

Wanneer een Windows- of macOS-computer een bestand kopieert via SMB, behoudt de NAS normaal gesproken niet de lokale gebruikersidentiteit van de clientcomputer. Het maakt het bestemmingsbestand aan als het account dat is geverifieerd bij de SMB-share, of als een account waaraan die sessie is gekoppeld.

Dit is waarom een bestand dat eigendom is van een Windows-gebruiker op de bron-pc eigendom kan zijn van kenneth, nasgebruiker, gast, of een andere NAS-zijde identiteit na de overdracht. Een opgeslagen SMB-referentie kan er ook voor zorgen dat de ene computer bestanden aanmaakt onder een andere eigenaar dan een andere computer.

Controleer de actieve SMB-gebruikersnaam in plaats van aan te nemen dat de desktop-login wordt gebruikt. Verbreek de share, wis indien nodig verouderde referenties en maak opnieuw verbinding met het NAS-account dat de bestanden zou moeten bezitten of beheren.

Share-toegang en bestandstoegang zijn aparte permissielagen

Een gebruiker kan de SMB-share openen en mappen bekijken, maar toch een bestand niet kunnen bewerken, hernoemen of verwijderen. Dit betekent dat de netwerkshare bereikbaar is; het bewijst niet dat het bestandssysteem de gevraagde bewerking heeft toegestaan.

Share-niveau regels bepalen of een SMB- of NFS-client de share mag betreden en of de verbinding als alleen-lezen of lezen/schrijven wordt gepresenteerd. Het onderliggende bestandssysteem evalueert vervolgens de eigenaar, groep, modusbits, ACL-items en overervingsregels voor elk bestand en elke map.

Los problemen op in beide lagen. Een share die als lezen/schrijven is gemarkeerd, kan een bestandssysteem-ACL die schrijven weigert niet overrulen, en permissieve bestandssysteem-modi helpen niet als het SMB-account door de shareconfiguratie beperkt is.

Windows-stijl ACL's en POSIX-modi komen niet perfect overeen

Windows-permissies kunnen meerdere gebruikers en groepen bevatten, expliciete toestemmings- en weigeringselementen, overervingsvlaggen en aparte rechten voor lezen, schrijven, verwijderen en wijzigen. Traditionele POSIX-modusbits beperken toegang tot eigenaar, groep en anderen.

Samba- en NAS-besturingssystemen moeten tussen die modellen vertalen. Een Windows Security-paneel kan een gedetailleerde ACL tonen, ook al ls -l alleen een vereenvoudigde weergave toont. Omgekeerd, het uitvoeren van chmod modusbits kan wijzigen zonder de Windows-stijl ACL die SMB-clients verwachten correct opnieuw op te bouwen.

Als de NAS-dataset NFSv4- of SMB-ACL's gebruikt, controleer dan de volledige ACL via de NAS-interface of een ACL-bewust commando. Ga er niet vanuit dat een bestand dat rwxrwx--- vertelt het volledige permissieverhaal.

UID- en GID-verschillen beïnvloeden Linux, NFS en apps

Linux-systemen bepalen eigendom meestal via numerieke gebruikers- en groeps-ID's. De gebruikersnaam is slechts een label dat aan die nummers is gekoppeld.

Twee systemen kunnen allebei een gebruiker met de naam media terwijl de ene UID 1000 gebruikt en de andere UID 1001. Voor Linux en NFS zijn dat verschillende identiteiten. Een bestand dat eigendom is van UID 1000 kan ontoegankelijk zijn voor een applicatie die draait als UID 1001, zelfs als hun zichtbare gebruikersnamen identiek lijken.

Controleer numerieke waarden op de NAS, host, client en applicatie:

id media
ls -ln /pad/naar/bestanden
stat /pad/naar/bestanden/voorbeeld.mkv

Vergelijk de nummers in plaats van alleen de weergegeven namen. Als meerdere systemen dezelfde opslag moeten beschrijven, stem dan de vereiste UID/GID-waarden af of maak een gedeelde groep met de juiste rechten.

SMB en NFS kunnen dezelfde dataset als verschillende gebruikers beschrijven

Toestemmingsproblemen verschijnen vaak geleidelijk wanneer SMB-clients en NFS-clients beide schrijfrechten hebben op dezelfde map. Bestanden die via SMB zijn geüpload, kunnen toebehoren aan één NAS-gebruiker, terwijl bestanden die via NFS zijn aangemaakt een numerieke UID van een ander systeem kunnen dragen.

De twee protocollen kunnen ook verschillende ACL- en identiteitskoppelingsregels toepassen. Hierdoor kan een map bestanden bevatten die voor een gebruiker identiek lijken, maar verschillende eigenaren, groepen, maskers of geërfde vermeldingen hebben.

Kies indien mogelijk één primair schrijfprotocol. Wanneer SMB en NFS een dataset moeten delen, stem dan numerieke ID's, gedeelde groepen, standaard ACL's, umask-waarden en aanmaakgedrag op elkaar af voordat je productiedata erin plaatst.

Docker-containers voegen een extra gebruikersidentiteit toe

Een bestand kan via SMB leesbaar zijn maar onbeschikbaar voor Plex, Jellyfin, Nextcloud, een downloader of een backup-container. Docker kan het juiste pad mounten terwijl het proces binnen de container nog steeds geen toestemming heeft om het te lezen of te schrijven.

Een containerproces draait onder een eigen UID en GID. Als die identiteit niet overeenkomt met de eigenaar of een toegestane groep op het gemonteerde NAS-pad, krijgt de applicatie Toegang geweigerd. Een volume-mount maakt de map zichtbaar; het omzeilt geen bestandsautorisatie.

Een veelgebruikte oplossing is om de container UID en GID te laten overeenkomen met de identiteit die het gemonteerde volume mag gebruiken. Controleer de werkelijke procesidentiteit in plaats van alleen te vertrouwen op een PUID- of PGID-veld dat in een Compose-bestand wordt weergegeven:

docker exec container-naam id
docker exec container-naam ls -ln /data
docker exec container-naam test -w /data && echo "Schrijfbaar"

De ene container kan bestanden aanmaken die een andere niet kan lezen

Dit gebeurt vaak in media-automatiseringsstacks. Een downloadcontainer schrijft succesvol een voltooid bestand, maar de mediaserver kan het niet scannen, of een organizer kan het niet hernoemen.

De applicaties kunnen verschillende UID/GID-waarden of verschillende umasks gebruiken. Als de downloader bestanden aanmaakt als 600, alleen de eigenaar kan ze lezen en schrijven. Een modus zoals 640 staat groepslezen toe, maar alleen wanneer beide applicaties de juiste groep delen.

Voor gedeelde applicatiemapgebruik, gebruik een geplande eigenaarsgroep, voeg de benodigde applicatie-identiteiten aan die groep toe en selecteer een umask die de groep de vereiste toegang geeft. Alleen oude bestanden repareren helpt niet als de downloader blijft doorgaan met het aanmaken van nieuwe bestanden met restrictieve modi.

Umask en serveraanmaakregels bepalen nieuwe permissies

Als oude bestanden werken maar elk nieuw bestand ontoegankelijk is, is het aanmaakproces waarschijnlijk de oorzaak. Elk programma begint met een gevraagde bestandsmodus, en de umask verwijdert geselecteerde permissies voordat het bestand wordt aangemaakt.

Samba kan ook instellingen gebruiken zoals aanmaakmasker, mapmasker, forceer gebruiker, of forceer groep. NAS-interfaces kunnen deze verbergen achter permissiesjablonen, gedeelde map-voorinstellingen of overervingsopties.

Maak één testbestand via elk pad: Windows SMB, macOS SMB, NAS-bestandsbeheer, NFS en elke relevante container. Vergelijk de resulterende eigenaar, groep, modus en ACL. Dit onthult snel welk aanmaakpad de gebroken permissies veroorzaakt.

Verschillende overdrachtstools behouden verschillende metadata

Finder, Windows Verkenner, een NAS-webinterface, cp, en rsync garanderen geen identieke resultaten. Sommige behouden tijdstempels, sommige kunnen POSIX-modi behouden, en andere maken simpelweg nieuwe bestanden aan volgens de regels van de bestemming.

Bepaal voordat u een migratiemethode kiest welke eigenschappen behouden moeten blijven:

• Bestandsinhoud en mappenstructuur
• Wijzigingstijden
• POSIX-permissies
• Eigenaar en groep
• ACL-vermeldingen
• Uitgebreide attributen
• Symbolische links

Voor gewone familiedocumenten of mediabestanden kan het erven van de bestemming de voorkeur hebben boven het behouden van broncomputeraccounts die niet op de NAS bestaan. Voor applicatiegegevens, Linux-home directories of servermigraties kan het essentieel zijn om eigendom en ACL-metadata te behouden.

Rsync behoudt niet elk attribuut met één eenvoudige opdracht

Rsync is nuttig voor gecontroleerde NAS-migraties, maar het resultaat hangt af van de opties, de privileges van de uitvoerende gebruiker en de mogelijkheden van de bron- en doelsystemen.

De archiefmodus behoudt algemene metadata, waaronder modi, tijdstempels, groepen en eigendom waar toegestaan. Extra opties zijn vereist wanneer de migratie permissies, ACL's en uitgebreide attributen met rsync moet behouden. Een typische Linux-naar-Linux test kan het volgende gebruiken:

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

De -A optie behoudt ACL's en -X behoudt uitgebreide attributen wanneer beide zijden deze ondersteunen. --numeric-ids moet bewust worden gebruikt omdat het behouden van een numerieke eigenaar die geen geldig account op de NAS heeft, precies de mismatch kan reproduceren die je probeert te vermijden.

Een SMB-gemounte rsync-bestemming gedraagt zich mogelijk niet als het NAS-bestandssysteem

Het uitvoeren van rsync vanaf een computer naar een lokaal gemounte SMB-share is niet altijd gelijk aan het uitvoeren van rsync via SSH direct op het NAS-bestandssysteem. De SMB-laag kan eigenaren toewijzen, ACL's transformeren of pogingen om attributen in te stellen weigeren.

De gebruiker die de SMB-kopie uitvoert, mag mogelijk geen willekeurig eigendom toewijzen, zelfs niet als rsync dit aanvraagt. Het doelsysteem kan ook een ander ACL-model ondersteunen dan de bron.

Test eerst een kleine representatieve map. Controleer de bestanden direct op de NAS na de overdracht, niet alleen via de gemounte share van de client. Bevestig eigendom, modi, ACL's, uitgebreide attributen en applicatietoegang voordat je het volledige dataset migreert.

NAS-machtigingsvoorinstellingen kunnen eenvoudige modusbits overschrijven

Sommige NAS-systemen beheren toegang via dataset-ACL-sjablonen en uitgebreide metadata in plaats van alleen traditionele eigenaar/groep/andere-modi. Dit kan een handmatige chmod lijken succesvol terwijl SMB of een applicatie de toegang blijft weigeren.

Een dataset kan ook zo zijn geconfigureerd dat geërfde regels opnieuw worden toegepast wanneer nieuwe bestanden worden gemaakt of wanneer machtigingen worden bewerkt via de beheersinterface. Het mengen van GUI-beheerde ACL's met herhaalde wijzigingen via de opdrachtregel kan een inconsistente staat veroorzaken.

Kies één machtigingsmodel en beheer dit consequent. Als het dataset is geconfigureerd voor een SMB/NFSv4 ACL, gebruik dan de NAS ACL-editor of ACL-bewuste tools in plaats van herhaaldelijk de structuur te vervangen met POSIX-moduscommando's.

Het opnieuw installeren van de NAS reset niet noodzakelijkerwijs de datamachtigingen

Machtigingen behoren meestal toe aan de bestanden en het bestandssysteemdataset, niet alleen aan de NAS-besturingssysteemconfiguratie. Het opnieuw installeren van het opstartsysteem kan daarom dezelfde ontoegankelijke eigendom en ACL-vermeldingen op een geïmporteerde opslagpool achterlaten.

Een TrueNAS-communitygeval illustreert hoe bestandssysteemmachtigingen gekoppeld blijven aan de opslagpool en moeten worden afgestemd op de juiste gebruikers en toegangsconfiguratie. Het toont ook het risico van het maken van grote recursieve wijzigingen zonder eerst het bedoelde identiteitsmodel te begrijpen.

Inspecteer vóór het herinstalleren of herbouwen van services de eigenaar, groep, ACL en applicatiegebruikers van de dataset. De data kan intact zijn en alleen de toegangsregels moeten correct worden hersteld.

Waarom recursieve chmod 777 geen echte oplossing is

Wanneer duizenden bestanden ontoegankelijk worden, chmod -R 777 lijkt een snelle manier om toegang te herstellen. Het geeft lees-, schrijf- en uitvoerrechten aan de eigenaar, groep en elke andere lokale identiteit.

Dat kan privégegevens blootstellen, ongewenste services toestaan bestanden te wijzigen, uitvoerrechten geven op gewone documenten en een zorgvuldig geërfde ACL-structuur beschadigen. Het corrigeert ook niet de verkeerde eigenaar, mismatch van container UID, ontbrekend groepslidmaatschap of kapotte SMB-identiteitsmapping.

Gebruik in plaats daarvan het bedoelde toegangsmodel: stel de juiste eigenaar en gedeelde groep in, bouw de juiste ACL opnieuw op, stel directory- en bestandsmodi apart in en corrigeer toekomstige overerving en umask-instellingen. Test op een kleine map voordat je recursieve wijzigingen toepast.

Herstel permissies vanuit de identiteit naar buiten toe

Begin met de geweigerde gebruiker of het proces in plaats van de opdracht waarvan je hoopt dat die het oplost. Een menselijke SMB-gebruiker, een mediaserver en een backup-container kunnen verschillende toegangsrechten nodig hebben.

Voor elke getroffen workflow, noteer:

• De gebruiker of het proces dat toegang probeert te krijgen
• De numerieke UID en GID waar van toepassing
• Het gebruikte protocol of de mount
• De huidige eigenaar en groep van het bestand
• De volledige ACL en geërfde vermeldingen
• De daadwerkelijk vereiste toegang: lezen, aanmaken, wijzigen of verwijderen

Pas daarna alleen de laag aan die fout is. Voeg de gebruiker toe aan een toegestane groep, corrigeer eigendom, herstel de ACL, stem een container UID af of werk de aanmaakregel bij. Vermijd bredere toegang dan de workflow nodig heeft.

Volg een gelaagde probleemoplossingsvolgorde

Het tegelijk wijzigen van de share-ACL, containeridentiteit, NFS-export en bestandsmodi vernietigt bruikbaar bewijs. Test één permissielaag tegelijk.

Begin met één getroffen bestand en één getroffen gebruiker of applicatie. Zodra die kleine casus werkt, maak je een nieuw bestand aan via de normale workflow en bevestig je dat de oplossing ook voorkomt dat het probleem terugkeert.

Voorkom permissieproblemen vóór een grote NAS-migratie

Het repareren van permissies over honderden duizenden bestanden is veel moeilijker dan het testen van het toegangsmodel vóór migratie. Maak een kleine doelmap met dezelfde ACL en applicatieconfiguratie die gepland is voor de uiteindelijke dataset.

Kopieer verschillende bestandstypen, geneste mappen, alleen-lezen bestanden, uitvoerbare scripts en bestanden met uitgebreide attributen. Test ze vanaf elk vereist pad: SMB, NFS, de NAS-interface, back-upsoftware en relevante containers.

Begin pas met de volledige migratie nadat nieuwe bestanden consequent de juiste eigenaar, groep, ACL en applicatietoegang krijgen. Maak een snapshot of back-up voordat je recursieve eigendoms- of permissiewijzigingen op bestaande data toepast.

Laatste conclusie

Bestandspermissies breken na het verplaatsen van data naar een NAS omdat de overdracht meestal nieuwe bestandssysteemobjecten aanmaakt. Die objecten worden beheerst door het NAS-account dat voor de overdracht wordt gebruikt, de doel-ACL, UID/GID-waarden, umask, protocolmapping en applicatie- of containeridentiteit.

Begin niet met chmod 777Beantwoord eerst drie vragen: wie heeft het bestand gemaakt, wie is nu de eigenaar en welke identiteit wordt geweigerd. Controleer vervolgens share-toegang, bestandssysteem-ACL's, erfenis, container-ID's en toekomstige aanmaakregels.

Een succesvolle reparatie moet twee dingen doen: het juiste toegangsniveau herstellen voor de bestaande bestanden en ervoor zorgen dat het volgende bestand dat wordt gekopieerd, gedownload of aangemaakt op de NAS automatisch de juiste permissies krijgt.

FAQ

Waarom erven gekopieerde bestanden de permissies van de NAS-map?

Een overdracht naar een NAS maakt meestal nieuwe bestanden aan op een ander bestandssysteem. Nieuwe objecten krijgen doorgaans permissies toegewezen vanuit de ACL van de doelmap, erfenisvlaggen en server-side aanmaakregels.

Waarom kan ik NAS-bestanden openen via SMB, maar mijn Docker-container niet?

De SMB-sessie en de container gebruiken verschillende identiteiten. Controleer de werkelijke UID en GID van de container, het numerieke eigendom van het aangekoppelde pad, groepslidmaatschap en of de koppeling alleen-lezen is.

Moet ik chmod 777 gebruiken om een NAS-share te repareren?

Nee. Het geeft elke lokale identiteit brede toegang, kan de ACL-erfenis beschadigen en lost geen onjuiste eigendom of UID/GID-toewijzing op. Definieer de bedoelde gebruikers en groepen en herstel vervolgens eigendom en ACL's dienovereenkomstig.

Kan rsync NAS-bestandspermissies behouden?

Het kan POSIX-permissies en andere metadata behouden wanneer de geselecteerde opties, uitvoeringsrechten en beide bestandssystemen dit ondersteunen. ACL's en uitgebreide attributen vereisen extra opties zoals -A en -X.

Waarom blijven nieuwe bestanden kapot gaan nadat ik de oude bestanden heb gerepareerd?

Het aanmaakpad is nog steeds verkeerd. Controleer de geërfde ACL van de doelmap, de SMB- of NFS-identiteit, de umask van de applicatie, Samba-aanmaakregels en de container UID/GID.