Assigning Ownership on a FAT32 USB Drive in Linux
Some applications refuse to run as root — Gitea and PostgreSQL are good examples. They have dedicated service accounts for security reasons, and they will flat out refuse to execute if you try to run them as root. This is fine under normal operation, but it creates a problem when you want to run a backup, a SQL dump, or a Gitea dump to a mounted USB drive. The application won't run as root, but the service account user doesn't have permission to write to the mount point. What do you do?
If the USB drive is FAT32, chown won't help you. FAT32 comes from the DOS/Windows world and has no concept of Unix file ownership — so chown will either fail silently or throw an error. When Linux mounts a FAT32 volume, it has to fake ownership and permissions for the whole filesystem at mount time, which means the fix happens at the mount level, not the file level.
Unmount the drive and remount it with the uid and gid of your service account user:
The entire volume will now appear to be owned by that user, and the dump or backup command will run cleanly under that account with full write access to the drive. When you are done, unmount and plug it out — job done.
If you plan to use this drive regularly for the same purpose, you can make the mount option permanent via /etc/fstab using the drive's UUID rather than the device name:
But for a quick one-time backup, the remount command is all you need.
Some applications refuse to run as root — Gitea and PostgreSQL are good examples. They have dedicated service accounts for security reasons, and they will flat out refuse to execute if you try to run them as root. This is fine under normal operation, but it creates a problem when you want to run a backup, a SQL dump, or a Gitea dump to a mounted USB drive. The application won't run as root, but the service account user doesn't have permission to write to the mount point. What do you do?
If the USB drive is FAT32, chown won't help you. FAT32 comes from the DOS/Windows world and has no concept of Unix file ownership — so chown will either fail silently or throw an error. When Linux mounts a FAT32 volume, it has to fake ownership and permissions for the whole filesystem at mount time, which means the fix happens at the mount level, not the file level.
Unmount the drive and remount it with the uid and gid of your service account user:
Code:
umount /mntmount -o uid=(id−uusername),gid=(id -u username),gid=(id−uusername),gid=(id -g username) /dev/sda1 /mntThe entire volume will now appear to be owned by that user, and the dump or backup command will run cleanly under that account with full write access to the drive. When you are done, unmount and plug it out — job done.
If you plan to use this drive regularly for the same purpose, you can make the mount option permanent via /etc/fstab using the drive's UUID rather than the device name:
Code:
blkid /dev/sda1
UUID=1234-ABCD /mnt vfat uid=1001,gid=1001,umask=0022 0 0But for a quick one-time backup, the remount command is all you need.
