Går säkert att kopiera med hårda länkar eller med 'reflink' (om nasen har BTRFS som filsystem) till för ändamålet skapade mappar i en gemensam delad mapp som båda kommer åt - Det som är knölet är användarrättigheter då användarkonton normal brukar vara skyddade för varandas insyn.
Kopiering utan att det tar extra diskplats (inom samma filsystem) kan tex. göras med 'cp -aln /user1/path/mapp1 /gemensam_mapp/path/mapp_user1' med hårda länkar och för reflink istället med 'cp -an --reflink=always /user1/path/mapp1 /gemensam_mapp/path/mapp_user1' för filsystem med BTRFS i NAS:en med en cron-script eller liknande.
(flagga -r gör att det kopierar rekursivt i mappträdet som skapar motsvarande kopia i mottagande mappträdet, flaggan -n i 'cp' gör att den inte skriver över filer med samma namn i mappträdet som finns sedan tidigare i en tidigare synkning. nu går förvisso skrivning av hårda länkar och "reflink" väldigt fort ändå även om det skriver över befintliga filer med samman namn i stora antal i mappträdet. -l (lilla L) säger åt 'cp' att hårda länkar skall användas, '--reflink=always' att 'reflink' (ny metadata som refererar till samma datablock av filen som orginalet och därmed inte behöver kopieras) alltid skall användas istället filkopiering eller använda hårda länkar i filsystem som BTRFS )
Den typen av kopiering med hårda länkar eller med reflink tar ingen extra plats på disken på NAS:en medans 'vanlig' kopiering tar lika mycket ny plats som storleken på filen/mappen man kopierar ifrån.
Kan också vara lite stök att sätta rättigheter (med chmod) på mappar i den gemensamma mappen och filer så att man kan titta på varandras filer och tex. bör tillhöra samma grupp (ofta 'user' i NAS-sammanhang) och default brukar då ena användare kunna läsa/titta den andre användarens filer men inte modifiera eller ta bort filerna förutom just sina egna filer.
---
Hårda länkar är en fil som finns på en plats men har flera filnamnsingångar som kan vara olika namn och som kan vara i olika mappar. Dess rättigheter och innehåll som ändras via en filnamnsingång speglas direkt för alla andra filnamn som är kopplade till filen. Man kan alltså inte sätta olika unika rättigheter för filen beroende på vilken filmap det refereras ifrån...
Detta är bra i en del sammanhang som att editerar man filen så är det uppdaterat på alla andra ställen i filträden samtidigt med filnamn som refererar mot samma aktuella fil. - nackdelen att det också kan användas oavsiktligt skadlig väg - att om den ändras på ett ställe också gör att det ändras på alla andra ställen som refereras till samma fil som tex. dagliga backup-mappar med sinsemellan hårdlänkade filer mellan sig.
Det beror på att filnamnen i en mapp innehåller bara ett nummer - en inod-nummer som pekar på själva filen - och inoden har all metadata som gäller för filen i avseende rättigheter, innehåll mm. och även räknare i hur många filnamn som pekar på inoden (men vet inte vilka då den inte har backreferenser och därmed kan hitta vilka filnamn som är refererad till samma inod) - När en filsnamn i en mapp raderas så minskas räknarantalet av filnamn på inoden och när den når 0 (dvs. inga filnamnsreferenser lägre existerar i filträden) anses filen raderad och filsystemet tar bort inoden i sin helhet och frigör platsen filen upptog till ledig utrymme i filsystemet igen.
Filkopia med 'reflink' är dock annan sak och kom först med COW-filsystem som BTRFS (och numera XFS, men inte opensourceversionen av ZFS ännu trots de gått över 10 år och verkligen behöver funktionen, bara i den senare kommersiella varianten av ZFS kort efter när den stängdes till sluten kod) - den har sin egna unika 'inode' och därmed kan sätta rättigheter individuellt för filkopian - men med COW-systemet i BTRFS så pekar den nya filen i samband med kopiering på exakt samma datablock som orginalet och kopian tar alltså ingen extra diskplats (mer än för den nya metadatan då) till en början och det är bara när man modifierar filen i endera sidan som nya datablock allokeras för förändringarna (och just dom delarna tappar då kopplingen mot originalet) - orginalet påverkas aldrig av man gör med kopian även om de till en början delade samma datablock.
