I just provisioned a new Bullseye OS on my RPi 3, installed Syncthing as a service running under a new user admin that I created, and then plugged in an NTFS-formatted 10TB USB drive. The drive already has around 3TB of data, an old copy of the server folder that I wish to resync to the RPi/USB combo.
Side note: the NTFS formatting is a requirement, as the drive serves as part of a disaster recovery plan for a Windows environment.
When I attempt to add a folder from the drive, however, I’m getting permission denied errors:
2023-02-08 09:25:54: Loading ignores: lstat /media/pi/D6986D4D986D2CE5/Files/Now/.stignore: permission denied
2023-02-08 09:25:54: Failed to create folder root directory stat /media/pi/D6986D4D986D2CE5/Files/Now: permission denied
2023-02-08 09:25:54: Error on folder "Files" (swnjz-jf5gr): stat /media/pi/D6986D4D986D2CE5/Files/Now: permission denied
Some relevant info:
The drive is auto-mounted somehow by the OS; /etc/fstab is pretty much empty
I ran sudo chown -R admin:admin /media/pi/D6986D4D986D2CE5 on the drive, which took at least an hour to complete
After the chown command completed, PCManFM still indicates pi as the owner in permissions
Read/write access to the drive is set to Anyone (see screen shot)
Here’s my lsblk output:
The odd thing is that I had this working at one time, under an older distribution on an RPi 4. In fact, that’s how the files got there in the first place. I can’t for the life of me figure out what’s gone wrong here.
I seem to recall something about having to manually configure the auto-mount under that older OS (it was a few years ago that I put the setup together), and then somewhere along the line having been pleasantly surprised at an apparently new Raspbian in-built feature that automatically mounts external USB drives. If this is the cost, though, I suppose I can do without (assuming the mounting process is somehow related to the error).
I’m at a loss here, friends. Do you have any ideas? How can I get Syncthing to work with my drive?
I believe the auto mount is a feature of the file manager used on Raspbian Desktop (with GUI), PCMan File Manager. Under the hood it probably uses udisks2.
Next, NTFS is kinda special in the Linux world. It doesn’t use the usual user id and group ids, but instead it works with “security identifiers” to identify owners, groups and permissions.
The usual driver for working with NTFS on Linux (NTFS-3G) has extensive support for the Windows permission model (and a mapping onto UNIX/POSIX models), but I’m not sure which of these options are enabled by default. I also don’t know which mount options are used by the automount (you can use the mount command to find that out).
You can look at the ntfs-3g manpage to see which options are available for mounting a NTFS filesystem.
As a starting point, you might want to look at the uid=value and gid=value options. Per the manpage:
Set the owner and the group of files and directories. The values are numerical. The defaults are the uid and gid of the current process.
You can also enable the ntfs-3g permissions system, which probably makes things like the chown command work. However, you might need to setup a user mapping file (see the manpage) and it could mess up file permissions under Windows, if not done correctly.
permissions
Set standard permissions on created files and use standard access control. This
option is set by default when a user mapping file is present.
Another option would be to try and grant syncthing more privileges, such that it can access files owned by the pi user. You can do this by giving syncthing the CAP_CHOWN and CAP_FOWNER capabilites. With these, syncthing should be able to access any file on the system (like it was running as root), but it doesn’t actually have to run as root. This is required for the new syncOwnership function of syncthing and explained in the docs.
Running syncthing as root of course is also a quick fix, but generally not recommended for security reasons.
Finally, syncthing also has “hardening” options in it’s systemd unit file (in case you use that). These hardening options are designed to deny access to certain sensitive files on the system - I’m not sure if access to /media is enabled by default. Therefore, this may be another thing that causes permission trouble.
(You can try to run syncthing manually, without systemd, to ensure that the permission errors are not caused by systemd hardening)
So I’m guessing it’s the latest major release of Raspberry Pi OS?
If so, it means it’s Debian for the Linux distribution and LXDE for the desktop environment.
It used to be that NTFS was the only viable option in a mixed OS environment that included Windows, but Dokany and other tools make it practical to use ext2/3/4 and btrfs on external storage (in particular, btrfs’ architecture, per-block checksums, plus other features are very useful on large volumes that contain lots of small files).
LXDE, the default desktop environment for Raspberry Pi OS, uses GTK and other tools from GNOME.
PCManFM talks to gvfsd which manages device mounts at the user level while /etc/fstab and autofs handle the system level.
Note that because NTFS doesn’t natively support Unix-style metadata, chown only lasts as long as the volume stays mounted. As soon as it’s unmounted and remounted again it’ll be “owned” by pi, or whoever is currently logged onto the graphical desktop environment at the time the USB drive is plugged in.
In the screenshot above, PCManFM is displaying the permissions for /media/pi, which is the parent directory for removable media that’s inserted by user pi.
Each removable media gets its own subdirectory (if a volume label is available, it’s used by default, otherwise it could be the UUID, system device name or something else).
The command sudo chown -R admin:admin /media/pi/D6986D4D986D2CE5 changed the ownership for /media/pi/D6986D4D986D2CE5 rather than for /media/pi, so PCManFM is correct.
Auto-mounting of USB drives in a desktop environment has been available in Raspbian/Raspberry PI OS since the early days, but support for NTFS required extra work (the ntfs-3g package often isn’t installed by default and built-in kernel support didn’t happen until 2021 (ntfs3 module starting with the 5.15 Linux kernel)).
Since you have Syncthing running under admin:admin, one option is to log onto the desktop as user admin before plugging in the 10TB USB drive so that the auto-mount will automatically set the ownership to admin:admin.
Another option is to manually unmount and then temporarily override the ownership during the mount like so (replace 1234 with the actual UID/GID assigned to your admin user):
The downside to the mount command above is that it assumes that your 10TB USB drive is always at device /dev/sda.
A better way is to use the volume label, device ID, UUID or other more consistent identifier. Because D6986D4D986D2CE5 is too random looking to be a volume label, I’m guessing it might be a serial number or some other auto-assignment. If you don’t already know which it is, issue the following command:
find /dev/disk -name D6986D4D986D2CE5
If it’s the partition ID, modify the mount command like so:
mount -v -type ntfs-3g -o uid=1234,gid=1234 /dev/disk/by-partuuid/D6986D4D986D2CE5 /mnt/10TB
If it’s the volume label:
mount -v -type ntfs-3g -o uid=1234,gid=1234 /dev/disk/by-partlabel/D6986D4D986D2CE5 /mnt/10TB
(As root, create the mount point with mkdir /mnt/10TB. Don’t worry about the default directory ownership because it’ll be temporarily overridden each time by the mount command.)
Optionally, for a /etc/fstab entry (adjust as needed for your /dev/disk pathname), add…
Yikes! Those were some beautiful answers—both of 'em. I’m humbled
In the end, though, my problem (technical, not social—social is a whole different ballgame ) was the permissions on the parent directory pi. They were set to the default Only owner, Only owner and group and Only owner. (I’m not sure how all of that corresponds with the CLI representation.)
Once I set them all to Anyone, the directories on the mounted USB drive became available in Syncthing’s auto-complete field, I was able to add them as Syncthing folders and presto! They started syncing.
) was the permissions on the parent directory 
