Cannot change ownership on some USB sticks?

[lah7]

Okay, so if /etc/fstab is OK, let's try deleting the directory where drives normally mount to.

Make sure all drives are unmounted/unplugged and this directory is empty, then run:

sudo rm -r /media/$(whoami)

Then try plugging one in again - this /media folder will re-created (correcting any permissions). The default expected behaviour is that it auto mounts and the window immediately appears.

---

Just so we're on the same page regarding this:

@computerguy

Since I cannot change ownership or perms on ANY of the many PCs that I have tried it on - this suggests to me that this IS exactly an OS centered problem as they ALL have the same OS...?

Are you referring to FAT32 formatted memory drives? If so, this filesystem has no concept of permissions, it is not possible to change ownership/permissions of files or directories of anything residing on a FAT32 file system.

Instead, the ownership/permission is determined by how it's mounted. Usually, this is automatically mounted under your user, but as you know, something is causing root to have ownership.

---

Since things were confirmed to work on a live session, a clean install is a last resort option.

[computerguy]

Thanks Again & Again Lah7.
I did mess up in a prior entry wherein I missed, then omitted mention of another HDD partition which is also in fstab - and which does appear with an entry in the /media directory.

That is currently & actively in use, and worse even still, since the strange bug activated by using GParted has funked-up Disks, I cannot easily get the info desired to change how it mounts until after my next reboot.

Given that I likely have about 2 weeks before I absolutely need this to have a complete solution...somehow - and WITHOUT anything as demanding as a totally clean install on the 'server' box it is needed for - I'll have to make that change sometime soon & return here with whatever results I get from it.

I still dearly wish for a way to have a totally permissionless system somehow !!
Thanks Again !!

[saivinob]

If I understood correctly,

• you insert an(y) USB stick formatted with FAT32 on your UM 18.04 machine(s), it is recognized, mounted and files show in file manager (Caja).
• You can open them (read) but you cannot edit them as normal user.
• As superuser sometimes edit works sometimes don't(?!).

You are saying it is always mounted as root? When you say read-only, it is read-only to the regular user correct?

Can you show output of following two commands when the USB is plugged in.

ll /media/$USER

and

mount

Following is info for my two FAT formatted drives (one SD card and another USB) as an example.

/dev/sdb1 on /media/sai/SDXC64G type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/sdc1 on /media/sai/TESTUSB type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Please share the output of cat /etc/fstab . @lah7 had already asked. We need to see the output. Not that we don't trust your word, but sometimes there could be some minor things (like typos) that affect, which we may not realize.

I tried to reproduce several times (on 18.04, 20.04 and 21.04) using several USB sticks but not able to make it fail (FAT32 mounting read-only and not allowing copy/paste, edits). I even used a USB that is showing symptoms of failure but even that mounts, edits (copy/paste) properly.

They ALL mount as being owned by the user, group also set to user - with file ACCESS ONLY - which will not change as user or superuser;
Also=> Others have just got ACCESS ONLY - which will not change as user or superuser.

• It is normal for USBs to mount as owned by user.
• Normal for groupname to be same as username.
• The 'Access files' permissions for group and others is also correct (which translate to r-x).
• I can confirm file manager does not allow changing permission from GUI while mounted. I tried to change permission from 'Access files' to 'Create and delete files' and it automatically reverted to 'Access files'. But this is not affecting my usage (read/write/mount/unmount as user)

However, what is not clear from your post is, what does it say for the user ? Does it say 'Create and delete files' or just 'Access files'? For me it says 'Create and delete files'. See below screenshot of my test USB for reference, which shows permissions as well.

Please post some screenshots.

[computerguy]

Thanks for such a comprehensive reply Saivinoba.
I'll answer to the best of my abilities...

To start with, this pertains specifically to 7 brand new 32GB Transcend sticks which all arrived formatted FAT32.

These will all be used for making scheduled/unattended backups via Grsync at a PC which is ~120 miles from my home that I can access remotely to monitor.
The success of this depends upon Grsync's unrestricted ability to add & remove files from each stick as they get rotated by a totally non-techie helper at that location once each week.
I have tried just copying & deleting files to several of them with somewhat random results - hence my concerns.

Upon insertion they show as owned by User - group=root & I'll try to attach a screenie showing this - it is as you said also, the 'access only' setting refuses to change via GUI - which seems to me as maybe being problematic.

Yes:

@saivinob

you insert an(y) USB stick formatted with FAT32 on your UM 18.04 machine(s), it is recognized, mounted and files show in file manager (Caja).

My concerns center upon file copying & deletions - which have been unreliable.

They mount as sdb#, of course and are all labeled backup.

ll /media/user - pertinent output:
drwxr-xr-x 2 user user 16384 Dec 31 1969 backup/

mount pertinent output:
/dev/sdb5 on /media/user/backup type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Why that says errors=remount-ro seems very concerning to me ??

cat /etc/fstab has no pertinent output relating with sdb5 at all.

[quote="saivinoba, post:28, topic:19186"]

• It is normal for USBs to mount as owned by user.
• Normal for groupname to be same as username. [/quote]

Not quite the same here...owned by user, groupname is root - which may be because user is a member of root also ??

Here is what I've been trying to describe:

If I try to change the group as superuser, it tells me this:

And now an oddity - I booted up the NB with 20.04, and was able to change the group, but that was all, as shown here:

Then upon plugging that same stick into my own desktop PC with 18.04.5, I was unable to reproduce the problem reliably - it now shows user for both, and cannot be changed, nor can it be renamed short of reformatting it.

There - it is now almost the end of my day & I very much hope that what I've posted here tonight will be enough in reply to your queries in trying to assist me ??

And:
Thanks Very Much for your time & efforts !!!

[jymm]

I am not sure this will help, but it would be worth a try.

Understanding File Permissions: What Does “Chmod 777” Mean?

Chmod 777: What Does It Really Mean? - Make Tech Easier

[saivinob]

@computerguy

To start with, this pertains specifically to 7 brand new 32GB Transcend sticks which all arrived formatted FAT32.

@computerguy

They mount as sdb#, of course and are all labeled backup.

ll /media/user - pertinent output:
drwxr-xr-x 2 user user 16384 Dec 31 1969 backup/

mount pertinent output:
/dev/sdb5 on /media/user/backup type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

We can discount the USBs now; Issue is not with the drives but with system configuration which most likely was modified by you.

The user 'user' should have 'user' group set, unlike in your case root. We do not know what other modifications are done on the subject machine. Not that it is wrong, just pointing out for troubleshooting. However even with this, I'm not sure why there should be any issue transferring data to/from a FAT32 drive, because the drive is mounted under logged in user with full access.

I must admit I noticed something which I had not given thought before. The 'Remove' and 'Rename' options are grayed out in file manager, as shown in screenshot below. Is that what you are talking about?

I am not sure if this is normal for mounted drive. I never bothered to rename, so I had not noticed.

When you say you cannot rename, how are you trying to rename? As the GUI way is not possible, I used fatlabel to change the drive name. Yes, this tool is not accessible by normal user. We have to use sudo but it did allow me to rename.

/dev/sdb1        60G   25G   35G  42% /media/sai/SDXC64G
/dev/sdc1       3.8G  5.6M  3.8G   1% /media/sai/E958-C095
(base) sai@hirsute:~$ fatlabel /dev/sdb1
open: Permission denied
(base) sai@hirsute:~$ sudo fatlabel /dev/sdb1
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
SDXC64G    
(base) sai@hirsute:~$ sudo fatlabel /dev/sdb1 TESTSDXC
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
(base) sai@hirsute:~$ sudo fatlabel /dev/sdb1
TESTSDXC   
(base) sai@hirsute:~$ 

The error message was probably because I tried to rename while drive was online. But sudo allowed me to change. If this was not the method you used, can you please try this and see if you have any luck?

Now, coming to data transfer, looking at your command outputs and screenshots, the drives are mounted correctly for normal access by logged in user (except on first screenshot it showed group 'root'). From what we see, you should not have problem in transferring data to and fro. At this stage I have to ask, from where are you trying to copy files? As you know, some directories are not accessible to normal user. Like, for example,

(base) sai@hirsute:~$ ls /var/lib/AccountsService/users/
ls: cannot open directory '/var/lib/AccountsService/users/': Permission denied

Make sure that the data you want to transfer are not inside directories not accessible by normal user (even sudo user is normal user until sudo rights are invoked).

Also, make sure you are not logging into one account, mounting drive and then have switched account (not purposely, of course) and trying to work on the drive. I haven't tested this (for FAT32 drive, I mean) but it may cause problem.

Lastly, for troubleshooting, please create a new user (not sudo/admin user, but normal user). Then try to mount USB and to copy files. This would help to isolate any configuration issue with first user 'user'.

[gordon]

@saivinob

I must admit I noticed something which I had not given thought before. The 'Remove' and ' Rename ' options are grayed out in file manager, as shown in screenshot below. Is that what you are talking about?

I am not sure if this is normal for mounted drive. I never bothered to rename, so I had not noticed.

Just thought I'd chip in that I can verify that such behavior is totally normal. The menu entries are for removing and renaming bookmarks. (Don't ask me why they get displayed even when the selected item is not a bookmark.)

[lah7]

@saivinob

As the GUI way is not possible, I used fatlabel to change the drive name.

Disks does support the renaming of drives, but it's a little less obvious: "Edit Filesystem"

(Because of FAT32, the name ends up in uppercase)

[lah7]

I concur with @saivinob that it's likely a configuration that's causing the issues, plus we also confirmed earlier there's no problems in a live session, so it would be good to distinguish if it's specific to that user or system-wide.

@computerguy

These will all be used for making scheduled/unattended backups via Grsync at a PC which is ~120 miles from my home that I can access remotely to monitor.

Just a thought, but will the local user far away be logged in with the same user account? There could be two scenarios to consider:

1. Local and remote user are both logged in as UserA. MATE auto mounts the drive locally, and the remote user would have no permission issues.

   • Except if trying to remotely access via certain GUI tools (like XRDP) which I found to have odd quirks with system level privileges. SSH would work fine.

2. Local user is UserA, remote user is UserB. MATE auto mounts as UserA, but UserB won't have permission as it's not mounted as them (note the uid=1000,gid=1000 in the mount options)

   • Unmounting/remounting would work without a hitch. Alternately it might be possible to set the mount options to allow other users (but it is a mount option, not a filesystem permission setting)

[computerguy]

Thanks for all the replies here Folks !!

The usernames (local & remote) will be the same.

As to renaming - the context menu in Caja for the stick itself has 'rename' greyed out, but as superuser it is not & it does work.

The files being backed up are all business documents, no system files or inaccessible directories are included.

A side question:
What might be affected if I formatted the sticks to exfat instead ??
It also is supposed to be 'permission free' similarly to FAT32, right ??

I will be making the trip there again in a week or so & trying to make the final adjustments & testing it all to verify that it can be handled by the helper since I am so far away normally.

Thanks again.

[lah7]

@computerguy

As to renaming - the context menu in Caja for the stick itself has 'rename' greyed out, but as superuser it is not & it does work.

Renaming partitions is a superuser/root privilege. Without having looked at the code, I would guess Caja only enables the option if your user is able to do it, but it doesn't go as far as escalating privileges (prompt for a password) to authorize the action (PolicyKit).

I think adding your user to disk might work in that case - but I wouldn't recommend this:

disk : Raw access to disks. Mostly equivalent to root access.

-- https://wiki.debian.org/SystemGroups

User groups is something we haven't checked actually:

groups

The default outputs:

[your username] adm cdrom sudo dip plugdev lpadmin sambashare

Creating a new user to test would help rule things out.

@computerguy

What might be affected if I formatted the sticks to exfat instead ??
It also is supposed to be 'permission free' similarly to FAT32, right ??

I haven't used exFAT, but it appears to be just as open as FAT32 with permissions. Though, your experience is likely going to be the same as it's not the filesystem's permission that's the problem, but rather how it's mounted.

[computerguy]

Thanks again Lah7.
A stimulating exchange to be sure...and also somewhat circular as your most recent closing thought seems to indicate:

@lah7

...it's not the filesystem's permission that's the problem, but rather how it's mounted.

Given that I do not know how I might change that function to be less lumpy, sometime after this week I'll be traveling for hands-on with the PC for which the sticks will be used, and will very carefully create & test the backup system so as to be sure it can read/write as completely as it should.
With any good fortune at all it will end up 'just working' such that my concerns over renaming, ownership & permissions can be left behind as having just been temporary obstacles along the way.

-IF- the process of making backup sticks of the documents remains too lumpy then I'll have to consider whatever other (non-internet using) options as may avoid said 'lumpiness'.
Only time will tell now, I guess.

[Lake_Lucian]

I have the same problem.
Why are so hard to change the permission to write on usb stick with just a simple right click?
Why is Linux, Ubuntu, etc so unfriendly ?
I can not go back to Windows, no way, but Linux is terrible with newcomers.
How can i recomand Ubuntu, Mint etc to any friend?
And the indications (like this and all the others) are never for the begginers.

[arQon]

Why are so hard to change the permission to write on usb stick with just a simple right click?

Because the root of the problem is that you don't have permission to modify the drive in the first place - and that includes the right to change permissions. Something of a catch-22, but deliberate and important.

I've also run into this problem at random intervals numerous times over the years, with REMOTE filesystems (SMB) as well as USB sticks. I haven't seen it in many months now, but in my case it was always fixed by a reboot for a while.

The only thing that vaguely comes to mind is that at some point I found a massive cache of gvfs "stuff", which I nuked, and I haven't seen the problem since. I also updated that machine to 20.04 somewhere in that interval, and it was intermittent to start with, so I could just be going through a lucky phase or etc. I suspect your problem has a different cause, but it's probably worth a shot since it has no negative impact.

I don't remember where the cache is (IIRC it's a pair of files per device/FS ever mounted) and I can't find it on the current machine, but I expect lah7 knows. If not, I'll check for it on that machine later.

[gordon]

@arQon

I don't remember where the cache is (IIRC it's a pair of files per device/FS ever mounted)

I'm getting deja vu from this comment! Remember this comment from May?

Caja - slow folder refresh

It's GVFS. It's under your home directory, specifically in ~/.local/share/gvfs-metadata. @arvindpmate, and after disabling all thumbnailing, delete the directory ~/.thumbnails in your home directory. This will get rid of existing thumbnails. (I deleted mine recently and discovered there were 25,864 thumbnails in that directory taking up a total of 36 MB of disk space!)

TL;DR: ~/.local/share/gvfs-metadata.

[computerguy]

@Lake_Lucian:
It is NOT that Ubuntu is unfriendly, specifically;
It -is- that ALL Linux distros are festooned with all sorts of 'security' things which can be 'root only' - hidden well - or very arcane, like what it takes to allow access to an Android device connected via USB.

My personal POV on this is that there is such a thing as being...
TOO SECURE !!!

Contrasted to that - as a devout, daily user of Ubuntu Mate - its wonderful stability & reliability (NO BSODs or random data losses - EVER) make it worth learning some things (like gaining root access as needed).

I'm a former windows tech - spent 20+ years struggling with all sorts of BS mostly in the service of users who ONLY 'knew' that forcing a reboot was their cure-all (that pretty much NEVER worked !!) and when that failed they thought doing a total OS re-install was OK even though they did not know how to back up their needed data & then would be FURIOUS over their own actions causing total losses.

A bit like this info actually:

IT Professionals Shared Their Funniest Stories On The Job — And I Suddenly...

At least when it comes to Ubuntu - a willing learner has many choices of communities in which to ask for info and help, and that alone makes it WAAAY better than windows - not even to mention all the horrible changes that M$ has made with which to afflict their users after they 'killed off' XP !!!

Best Wishes.

[arQon]

@gordon

I'm getting deja vu from this comment! Remember this comment from May?

heh - indeed so.

I'll note that my reply at the time also remains as true as it was then:

As opposed to under ~/.cache, where it belongs, which is why I can never find the damn thing!

Now we just need OP to see if it helps. My guess is not, but it has to be worth a shot.

[arQon]

@computerguy

My personal POV on this is that there is such a thing as being...
TOO SECURE !!!

I don't think that's actually your POV at all. What you're really objecting to is "security theater", i.e. using the label of security as a pretense to avoid addressing bugs or bad design and decisions. (Wayland is the current poster child for this, but plenty of other pieces are in the same boat, including ssh).

Authorization

[Sam_Vanderleyden]

Wow, This is enormous.
I'm blown away by the contradiction between the simplicity, though genuinely relevant and basic (in all honesty) of the issue of the TS and the impressive storm of answers and deep diving to be able to solve this.
It is indeed mind baffling and unacceptable that changing group ownership on external drives with the easiest of commands (chown -R :mycustomgroup /media/user/mydrive) cannot be done.
I came to understand the underlying problem of the nature filesystem at hand , but come on, really?
I really stand behind the remarks and comments of 'computerguy' who spend really so much of his time to spit this out.
But looking it from a overview perspective, to me it signify's something really week in the vision about automounting drives and auto-settings of owners. I mean ... nope , not good.
Do we, do you, really expect every "normal" user (noobs)... to start editing the fstab file before even mounting drives??? Does anyone here pretends in a retrogade-elitist mood of linux-the-old-says and still dareqs to make comments like "yeah, but you should know this things before even attempting to run linux OS (any)... No that's not the way.
To put it this way: people should have to know about fstab in order to be able to make usb drives accessible to other users. If that still is the way, than the bar is to high and it still a burden on the success and popularity of linux OS' .

[computerguy]

ABSOLUTELY BRILLIANT reply by Sam_Vanderleyden - thanks so much !!!

And...still a very nasty sticking point which AFAIK, remains UNSOLVED.

In fact, I've just posted this thread which is very related:

Endless USB PITAs - which should NOT even exist at all!

I've posted about such 'paper cuts' before, over a period of several years - and nothing about this has really gotten any better from what I can see. Conundrum: I'm here alone - using MY own PC - and I plug in USB device 'x'... Does it read & appear ?!? To get the answer - roll some yes/no dice !! (And watch the contradictions appear.) Desire: Same situation - same action... Device is read and appears - PERIOD. Best/worst example: A genuine gripe as well here=> I have a truly beloved …

Too many little niggly & truly stupid little 'paper cuts' that have been mostly ignored with workarounds that AREN'T functional or within reach of most users.

Because of these sorts of things I haven't posted here in a while - when I did it brought me some small satisfactions now & then, but I have found it to be easier to just use U/M & not ask for help because there's still LOTS of stuff for which no solution exists...OR:

Merely doing a general/open DDG search will reveal goodness or a total lack thereof - in which case it is time to just=>
Give that query up rather than banging one's head against it.

And SPECIFICALLY regarding this EXACT topic:
If/when I get TOTALLY stumped by not being able to read/write my own USB media after a couple of tries with or without using root access - I change the venue, which REALLY annoys me - and give in to firing up that OTHER OS - which I would totally prefer NOT TO NEED anymore for anything, EVER.