I have taken a user’s %userprofile% folders (such as Desktop, Documents, etc) and synced them to other Windows PCs. The intermediary device runs Linux. When I create a file on Win PC’s “Desktop” it appears on Win Laptop’s “Desktop”.
For example:
Win PC “C:\Users\x\Desktop” ↔ Linux ↔ Win Laptop “C:\Users\x\Desktop”
From my research, when you customize a folder icon in Windows, this icon information is added to a hidden “desktop.ini” inside the folder, and Windows sets the folder as “read-only” to indicate that the folder has been customized (a non read-only folder’s desktop.ini is not respected)
In addition to having the files locally on a Windows PC, I tried sharing the files using Samba from the Linux device.
In this scenario, files inside an iconized folder become unwritable (“Desktop” is dr-xr-xr-x) but files inside subfolders can be (“Desktop\subfolder” is drwxr-xr-x)
So the issue is threefold:
Windows uses this read-only attribute in a less-than-expected manner
Syncthing respects it (as it should)
Samba takes the read-only attribute literally and Samba prevents me from modifying my own files.
Of the above variables, I think what I can change is Syncthing - setting a folder to “Ignore Permissions” on the Linux device.
One side effect would be that folder icon changes would not be synced and I would have to apply them manually, but that’s a small issue. Anything else (modifying Samba behaviour) seems too complex.
Does disabling permissions seem like the correct thing to do in this scenario?
If a device has the storage capacity, then it gets all the %userprofile% folders via syncthing.
Linux server ↔ syncthing ↔ Windows PC(s)
In this case the Windows PC is a normal device with “modern” computing and storage abilities. I’ve been doing this since about 5 years ago with fantastic results (praise be to syncthing).
Planned scenario
I’m currently implementing a scenario where I have low-powered PCs that have no need or capability for file sync, whether due to lack of storage or otherwise:
Linux server ↔ syncthing ↔ Windows PC(s) [existing]
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ↔ samba ↔ Thin client [new]
Where the Thin client is an anemic device (something like a Raspberry Pi or an actual thin client). I would be able to access my %userprofile% via mapped network drives, where the Linux server previously serving files via syncthing now serve those same files via samba (hence my post).
All-syncthing scenario
The original plan was to do it all with syncthing:
Linux server ↔ syncthing ↔ Windows PC(s) [existing]
The benefit is that VM would look and feel just like a normal PC, and it would be essentially a “fat client”, with all files stored locally. Meaning, what is on the Desktop is physically there, and not accessed via mapped drives, and the user could “customize” the VM as they would a physical machine. However since the VM is actually running on the Linux server, the same files would be stored twice, which seemed like a waste of space.
Abandoned scenario
I also considered using a VM where the VM will access files via samba rather than syncthing:
Linux server ↔ syncthing ↔ Windows PC(s) [existing]
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ↔ samba ↔ VM ↔ RDP ↔ Thin client [new]
I think this last method is overengineered and having neither the benefits of either scenario, you have a VM but it uses mapped networked drives: you could have just mapped the network drives directly and skipped the VM
I’m glad you asked, I hope that someone tells me my plan is very convoluted and guide me back to the correct way
Sure, I can see how that might work, even if it’s potentially overkill.
Under the classic definition of a “thin client”, the planned scenario above isn’t feasible.
Although it’s possible for a thin client to connect to Samba, there’s normally no desktop application software other than a remote desktop client to make use of files available via the network share.
Although it seems like syncing shared files to the VM is a waste of space, it’s really no different than the bare-metal client. In both instances files are being duplicated.
You didn’t mention concurrency – i.e., does a given user log onto multiple Windows desktops at the same time?
The scenario above with Syncthing mirroring %USERPROFILE% (e.g., C:\Users\rubber_gun) would very likely result in file conflicts.
Skipping the VM for the thin client really isn’t an option…
Without the VM, your “thin client” takes the place of the VM and becomes just another Windows PC “desktop client”.
A thin client that can map a network share and provide a user friendly desktop environment would no longer be classified as a “thin client”, especially when Windows is providing the DE.
(Microsoft used to sell “Windows Thin PC”, a 32-bit only special edition of Windows 7 intended for lightweight clients. The ISO image is ~1.5GB, with a base install plus updates clocking in at around 7.7GB. In comparison, a full Linux DE is typically half that size, and a Linux thin client can be under 100MB.)
Not convoluted, but perhaps overthinking it…
If there are no issues with maintaining network connections, the most common roaming profiles setup with a Linux server and Windows desktop clients is:
Linux server ↔ Samba ↔ Bare-metal Windows PC
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ↔ Samba ↔ Virtual Windows PC ↔ RDP ↔ thin client
If your Linux server is powerful enough to host Windows VMs, from a maintenance and security point of view, the Samba server should also be a VM.
Linux server ↔ Samba VM ↔ Windows PC
The Windows PC(s) can be a mix of bare-metal and virtual machines.
Pros:
Lower chances of file conflicts compared to mirroring files with Syncthing, rclone, rsync or some other sync tool.
Reduced storage requirements for the roaming profiles.
Cons:
Single-point-of-failure because all of the Windows desktop clients are reliant on the Samba connection. Of course, there are various ways to provide high availability.
Which hypervisor platform is hosting the VMs on the Linux server?
The file attribute for desktop.ini is set to hidden, but Windows doesn’t actually set the parent folder to read-only.
Windows Explorer oddly offers three states for the “Read-only” attribute even though at the filesystem layer it’s either on or off.
Default (note the semi-grayed out checkbox):
On:
Off:
See the create mask and directory mask parameters in Samba for overriding permissions bits in Unix/Linux.
Enabling “Ignore Permissions” in Syncthing on the Linux server is certainly an option, but then the umask for the user running Syncthing will control what the permission bits are.
You didn’t mention if there’s just a single instance of Syncthing on the Linux server, or if there’s one per Windows user, so I can’t provide any additional insight.
Thanks a lot for the feedback; clearly you know your stuff well! It’s been a pleasure reading what you wrote. I think your points boil down to the following:
I use the term "thin client" casually to refer to a minimally configured (Windows) PC where you refer to an actual thin client.
I have never used one, but I imagine, akin to what you say, on a real thin client aside from a “IP” field and a “connect” button, there probably wouldn’t be much else to manipulate, hence indeed mapped drives would be untenable.
A VM is not much different from a bare-metal client.
I never thought of it that way. In a storage-space-used sense, you are correct.
%userprofile% syncing may be problematic.
You’re correct, when I undertook this endeavor years ago I noticed %APPDATA% folders to always seem to cause trouble with files always in use; without testing it seemed likely that a program that works with databases like Chrome would not take kindly to its internal data being modified. In that end, I used a whitelist-based system to only sync the user/non-system folders (Desktop/Docs/Downloads/Music/Pics/Vids).
In terms of concurrency, I would say the usage pattern is a home-user type, with failry standard syncthing settings relating to watch/rescan/exclusion (e.g. .crdownload), and not needing to work on the same file on two devices simultaneously, I have not seen file conflicts for a long time.
Using Samba instead of syncthing.
The reduced storage needs are appealing, I agree with your pros and cons. Tailscale or another VPN would be all one needed to get this up and running. It also seems like a more standard way of doing things, perhaps in the enterprise?
However, all my workflow is all syncthing-based, and being able to be offline has never been necessary but a source of inertia towards switching… Strongly considering experimenting with this in the future.
To answer your question: the Linux server runs Proxmox, and the VMs run on top of it. Samba runs in a LXC container, so I guess that fulfills your point of “the Samba server should also be a VM”.
In short, the samba-based solution seems appealing, and probably something I’ll try implementing in the future.
I have only one instance of Syncthing, which runs as my user. Each Windows PC runs Syncthing which shares their folders to it. Since this is a home setting, and I have permission to do this from the users (family), this is a lot simpler than running multiple Syncthing instances and dealing with Linux permissions. All the users’ file ownership is by me.
I have played around with these mask options in the past, with the purpose of having Samba-created files follow the Linux umask. However, I don’t quite follow. In which situation that you recommended are you doing this (i.e. is it the PC/VM ↔ Samba), and what problems do you solve by doing so?
The linked clone feature in PVE can help simplify maintenance and dramatically reduce storage requirements when there are multiple VMs with the same OS.
It’s applicable to both bare-metal and virtual Windows PCs…
Similar to how you’ve been managing all of the different Windows users via a single Syncthing instance on your Linux server in order to simplify file and directory permissions, Samba’s create mask, directory mask, force user and force group parameters can be used to consolidate all Windows users’ files under a single Linux user without requiring matching user credentials between Windows and Linux (i.e. a Windows user normally has a username and password that’s also used to access a Samba network share on a Linux server).
Although it might be tempting to put all of %USERPROFILE% on a Samba share, it’s not worth the hassle because %LOCALAPPDATA% wasn’t designed to be part of a roaming profile. It’s better to selectively redirect %USERPROFILE%\Desktop, %USERPROFILE%\Documents and other subfolders are needed.
Then Syncthing can be run alongside Samba to sync selected items under %LOCALAPPDATA%.
