Users directory als mountpoint is geen goed plan

[striper]

Ik had al een tijdje het probleem dat mijn 120GB SSD volliep. Een paar keer zaken opgeschoond, maar dat was natuurlijk uitstel van executie. Aangezien ik nog een 120GB SSD had liggen, dacht ik een slimme oplossing bedacht te hebben door deze tweede disk te mounten onder C:\Users. Om dat voor elkaar te krijgen, moest ik al door aardig wat "hoops"springen:

• Eerst bootte ik in een repair console via een USB stick met daarop de laaste Windows 10 2004.
• Rename C:\Users naar C:\Users.old
• mkdir C:\Users
• Volume aanmaken op de nieuwe SSD en mounten onder C:\Users (geen driveletter) middels diskpart.

Daarna moest natuurlijk de data onder C:\Users.old naar C:\Users gekopieerd worden. Ik dacht even simpel een robocopy te doen, maar ik liep natuurlijk tegen de beroemde junctions aan die ruim aanwezig zijn in C:\Users. Via de help kwam ik gelukkig de -naar later bleek gloednieuwe- optie /SJ tegen die junctions mee kopieert (zie ook https://gathering.tweakers.net/forum/list_messages/2001048).
Na een reboot leek Windows gewoon te werken, maar ik liep al vrij snel tegen problemen aan:

• Onedrive weigert te synchroniseren in C:\Users\<username>\Onedrive. Uiteindelijk kon ik dit oplossen door de tweede disk alsnog ook van een driveletter te voorzien en Onedrive te vertellen dat hij daar naartoe moest syncen. Helaas lukte me dit alleen voor de O365 versie en niet mijn Personal Onedrive account
• Windows search weigert directories onder C:\Users te indexeren. Ze zijn simpelweg niet te selecteren!
• Aangezien ik nog Windows 1909 draaide, probeerde ik te upgraden naar 2004. Helaas hagelslag, ook dit mislukte met een vage foutmelding. Diep in de logs kwam ik uiteindelijk een melding tegen die iets zei als "cannot find user profile in C:\Users\<username>

Conclusies:

• DON'T use a mount point for C:\Users!
• DON'T try to be smart with Windows
• Windows !== Linux

Uiteindelijk heb ik een 500GB SSD gekocht en de hele boel daarop overgezet. Weer wat geleerd

[Sebazzz]

Je had ook slechts de Windows profielen kunnen verplaatsen en dat wordt wel ondersteund.

[maubaan]

had je de 2 schijven niet beter in Raid kunnen zetten en zo een grotere schijf te krijgen?
Dit moet je moederbord natuurlijk wel aan kunnen

[MsG]

Je moet dit niet zo houtje touwtje doen, maar je kan dit prima officieel verplaatsen.

Ik doe altijd mijn submappen van de Userfolder door met rechtermuisknop er op te staan in verkenner en dan iets van "locatie aanpassen". Wil je de hele Userfolder op een ander pad dan moet je met het register aan de slag. (https://superuser.com/que...le-location-in-windows-10)

Overigens is er altijd van die crappy software die hardcoded in alles van C:\ uit gaat in plaats van het degelijk gebruik van omgevings/systeemvariabelen.

Ik heb die profile-wijziging jarenlang gedraaid op een Windows 7-machine met krappe 120GB SSD.

[Squ1zZy]

<verwijderd>

[ Voor 90% gewijzigd door Squ1zZy op 08-11-2020 17:14 ]

[striper]

Sebazzz schreef op dinsdag 16 juni 2020 @ 08:32:
Je had ook slechts de Windows profielen kunnen verplaatsen en dat wordt wel ondersteund.

Had idd ook gekund, aleen had ik geen zin om op 10000 plaatsen profielpaden aan te passen. Natuurlijk zou idealiter alles naar %UserProfile% moeten wijzen, maar in de praktijk is dat een heel ander verhaal.

Mijn punt is meer dat ik geen verklaring heb waarom mounten niet werkt. Ik heb niet getest of een junction hetzelfde resultaat oplevert, maar dat is een techniek die MS zelf veel toepast in de profielen en daarbuiten. Een mountpoint is technisch toch min of meer hetzelfde, zou je zeggen

[Sebazzz]

Hoeveel profielen moet je verplaatsen dan? Je kan gemakkelijk het profielpad aanpassen, desnoods een replace in het registry uitvoeren en als fallback een directory junction maken op de originele plek. Dat heb ik ook gedaan (wel op Windows Server dan) en werkt perfect

[Question Mark]

striper schreef op dinsdag 16 juni 2020 @ 09:57:
[...]
Mijn punt is meer dat ik geen verklaring heb waarom mounten niet werkt.

Als jij simpelweg "mkdir C:\Users" gebruikt om een folder aan te maken, dan zijn de security rechten op de folder op detailniveau al verschillend. Daarnaast heb je de userprofiles gekopieerd, waardoor het ownership ook nog eens aangepast is.

Je geeft niet aan welke parameters je allemaal gebruikt hebt bij je robocopy actie, maar mijn vermoeden zou zijn dat je tegen een rechten of ownership probleem aanloopt.

Overigens raadt MS het verplaatsen van deze folders zelf al af:

Relocation of the Users directory and the ProgramData directory to a drive other than the drive that contains the Windows directory

[McKaamos]

Sebazzz schreef op dinsdag 16 juni 2020 @ 08:32:
Je had ook slechts de Windows profielen kunnen verplaatsen en dat wordt wel ondersteund.

Dat ja. Eigenschappen -> Lokatie -> andere mapnaam/lokatie opgeven.
OK rammen en dan vraagtie of alles verhuist moet worden.

[Sebazzz]

McKaamos schreef op dinsdag 16 juni 2020 @ 10:12:
[...]

Dat ja. Eigenschappen -> Lokatie -> andere mapnaam/lokatie opgeven.
OK rammen en dan vraagtie of alles verhuist moet worden.

Dat is niet hetzelfde. Dat is de locatie van de well-known mappen in het profiel verplaatsen. Wat ik bedoel verplaatst ook de Application Data mappen, waar vaak ook veel in gaat zitten (o.a. temp files).

[HollowGamer]

@striper Windows is inderdaad geen Linux. Bij de laatste kan je gewoon* /home mounten op een aparte schijf of partitie.

Overigens raad ik ook daarbij aan dat je niet mkdir, cp -r, etc. aan de slag gaat. Het is echt belangrijk dat je bijvoorbeeld de rechten overneemt (eventueel timestamps), zoals met een tool als rsync (genoeg tutorials op het web) of een goed backup/restore programma (borg anyone?).

Ik vraag mij dan ook echt af of je niet de Windows-installatie hebt gesloopt, in Users staat naar mijn weten ook de DefaultUser en andere belangrijke zaken.

[ Voor 9% gewijzigd door HollowGamer op 16-06-2020 10:25 ]

[Starke]

MsG schreef op dinsdag 16 juni 2020 @ 08:41:
Je moet dit niet zo houtje touwtje doen, maar je kan dit prima officieel verplaatsen.

Ik doe altijd mijn submappen van de Userfolder door met rechtermuisknop er op te staan in verkenner en dan iets van "locatie aanpassen". Wil je de hele Userfolder op een ander pad dan moet je met het register aan de slag. (https://superuser.com/que...le-location-in-windows-10)

Overigens is er altijd van die crappy software die hardcoded in alles van C:\ uit gaat in plaats van het degelijk gebruik van omgevings/systeemvariabelen.

Ik heb die profile-wijziging jarenlang gedraaid op een Windows 7-machine met krappe 120GB SSD.

Let wel dat die sysprep (tenforums genoemd topic in de superuser thread) oplossing sinds Windows 8 not done is. Dit werkte nog met Windows 7 en dan SP1 / SP2 upgrades maar als je Windows 8 gebruikte en dan naar 8.1 wou gaan met die oplossing > nope en met Windows 10 en elke major version upgrade is dit hetzelfde.

Sinds Windows 8 verplaats ik dus alleen maar de folders van de userprofiles (lees onderliggende folders als Documents, Downloads, Pictures, etc.). En als je nog wat extra wil besparen zou je in Environmental Variables de %TMP% en %TEMP% (sysdm.cpl) nog naar een andere schijf kunnen verplaatsen.

Maar grotere SSD is dus min of meer de enige oplossing daarvoor gezien met Appdata etc verplaatsen je problemen gaat krijgen met W10 (W8) apps .

[striper]

foxgamer2019 schreef op dinsdag 16 juni 2020 @ 10:23:

...
Overigens raad ik ook daarbij aan dat je niet mkdir, cp -r, etc. aan de slag gaat. Het is echt belangrijk dat je bijvoorbeeld de rechten overneemt (eventueel timestamps), zoals met een tool als rsync (genoeg tutorials op het web) of een goed backup/restore programma (borg anyone?).
Ik vraag mij dan ook echt af of je niet de Windows-installatie hebt gesloopt, in Users staat naar mijn weten ook de DefaultUser en andere belangrijke zaken.

Ook @Question Mark:
Uiteraard heb ik na het aanmaken van de C:\Users directory, robocopy alle parameters meegegeven om de ACL's e.d. mee te nemen (/COPY:DATSO /DCOPY:T) inclusief de junctions. Default User/All Users komen ook netjes mee met de nieuwe /SJ switch en /SL voor eventuele (file)symlinks. Het zag er allemaal gewoon helemaal echt uit ...alleen werkten sommige Windows onderdelen gewoon niet.
Dat MS het afraadt is geen verklaring waarom het niet zou werken. Blijkbaar zijn mountpoints en junctions niet zo transparant als je zou willen voor de processen die er gebruik van maken.