vfat partition as /home mountpoint in an embedded Linux system

Question

Usually, in my embedded projects I set up the SD card with the following structure:

• boot: FAT32 (not mounted)
• rootfs: ext4 (mounted in ro)
• home: ext4 (mounted in rw)

(The current project uses an RPi 3 - just in case we need to talk somewhat specific.)

The boot and rootfs partitions are kept as small as possible. Instead the home partition occupies all the available space on the SD card (max 32 GB).

The home partition will contain the application specific files (executables, configuration, logs, etc...) along with the user files (i.e. multimedia, icons, or any other file that belong to the user.

To let the user to access his own files I set up a Samba share on specific folders.

Now I have a new request: make the home partition FAT32. In this way (he says) it would be easier to update files even without a network connection, just inserting the SD card in a Windows PC.

Few questions:

• what about using a VFAT partition for the /home mountpoint?
• as said, that partition contains also the executables and symlink to some configuration files like /etc/network/interfaces and similar. Any caveats here? I'm afraid the lack of GID/UID support.
• any suggestion about how to manage the user/data partition in an embedded system (headless) allowing the final user to easily access the files?

Answer 1

Keep in mind that Windows will only mount the first listed partition on any removable disk. I'm not sure whether it's the first of them all or the first with a filesystem Windows can understand. Either way it would be /boot in your current setup, I guess.

I don't know if you can create your /boot partition as the second one or further; or to change its filesystem. I mean: I think it's possible with Linux and GRUB but I have some experience with Raspbian on RPi and it doesn't use GRUB.

So probably this settles it. Or maybe not. Read this answer on how to hide a partition from Windows, it should work with FAT32 as well.

---

In case you managed to overcome the above issue, there are others:

I'm afraid the lack of GID/UID support.

And you're right.

• If more than one user, users will be able to read somebody else's files. But it looks like there's one user only, right? I assume so.
• Compare this and this. SSH key-based authentication won't work.
• More programs may be affected in a similar manner.

This answer says it might work with NTFS. I think NTFS support in Linux is done with FUSE. Read these security concerns.

Also:

• FAT32 is designed as case-insensitive. Some programs may rely on case-sensitivity of the filesystem (e.g. a program uses both A_file and a_file).
• As far as I know there's no journalling in FAT32.

any suggestion about how to manage the user/data partition in an embedded system (headless) allowing the final user to easily access the files?

Should the user edit "application specific files" on Windows? Consider vfat only for "multimedia, icons, or any other file that belong to the user". This would be mounted separately to a location other than /home. On the other hand nowadays 32 GB is not a lot and you may not want to split it further.

---

There's one more solution: let the final user use Linux.

Answer 2

Easy to try, you cannot make a symlink in a vfat partition. ln -s says "operation not permitted". So VFAT seems out for /home. However, you can have an extra VFAT partition and have symlinks to files/directories on it from a regular ext4 filesystem.

If you have SSH access you can use SFTP to manage files on the RPi, it shouldn't be hard to find clients (ie, SFTP-aware file explorers). You just need to set up an SSH key, but it's trivial (and will keep out $prankster who would access your RPi).