Permission denied on USB drive

[gadget]

@InteXX

I just provisioned a new Bullseye OS on my RPi 3, installed

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.

Side note: the NTFS formatting is a requirement, as the drive serves as part of a disaster recovery plan for a Windows 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).

Some relevant info:

• The drive is auto-mounted somehow by the OS; /etc/fstab is pretty much empty

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.

• I ran sudo chown -R admin:admin /media/pi/D6986D4D986D2CE5 on the drive, which took at least an hour to complete

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.

• 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)

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.

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).

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)).

I’m at a loss here, friends. Do you have any ideas? How can I get Syncthing to work with my drive?

Expanding on what @Nummer378 has already covered…

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):

umount -v /media/pi/D6986D4D986D2CE5
mount -v -type ntfs-3g -o uid=1234,gid=1234 /dev/sda1 /mnt/sda1

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…

/dev/disk/by-partlabel/D6986D4D986D2CE5  /mnt/10TB  ntfs-3g uid=1234,gid=1234 0 0

… then your mount command can be shorted to…

mount -v /mnt/10TB

It’s simple, clean, and portable so it won’t break between OS upgrades.