No, your rant just proves the point a new USB drive is not always a good, trouble free USB drive.
That this problem is 100% repeatable and remains UNSOLVED is just shocking to me !!!
I am finally past most of the other goofy papercut type problems and need to finally implement the planned backup system, thus enabling both on-site and off-site data storage separate from the 'server'.
This involves 7 (or more) just purchased USB sticks - all identical Transcend 32GB sticks - literally BRAND NEW & unpackaged by my own hands.
They arrive 100% empty, FAT32, and mount fine - but guess what ?!?
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.
Grabbed it inside GParted, deleted that partition - re-created an extended then a logical inside it as FAT32 - and THE SAME THINGS ALL HAPPEN !!!
(And my old favourite too - then the Disks app goes all funny post GParted usage...another papercut - meh.)
So, I stuff that stick into the handy XP box - and it plays nice ONE HUNDRED PERCENT - no overbearing & incorrect permissions BS or anything.
This baloney is UNCHANGED & UNFIXED after almost a year that I know of, and in plain, simple words:
This NOT being fixed just plain old s*cks !!!
Let's look at some troubleshooting:
- Do these USB sticks mount correctly when you boot into a live session (from USB or DVD)?
- Is the problematic computer running a 32-bit copy (i386) or a 64-bit version (amd64) of
? - Are you still running 18.04?
- Are you able to boot a live session on the XP box? If so, do the USBs mount correctly there?
I'd like to know if this problem happens under a "clean" environment on the same computer without the need to reinstall the OS, and also briefly check the same USBs on a different computer running .
FAT32 has no concept of file permissions, so the issue has to lie with how it mounts.
1 Like
Thanks for your reply Lah7 !!
In the order asked=>
1 - Yes.
2 - 64 bit.
3 - Yes. 18.04.5 - by preference - tried 20.04.1 on my 'play' box - was NOT impressed.
4 - My XP PC is a stripped down, formerly w7 NB now with XP & it does all the things fine EXCEPT when booting some older windoze things that do not recognize the needed USB KB & mouse.
As to booting a 'clean' OS on this exact box - it is my daily driver, used literally ALL the time when I am awake - so messing around with it is problematic for me, BUT:
When I was getting it ready to put into place (months ago...) I did test it with a bunch of sticks & they booted & read as they needed to.
As to different PCs - I have several more at my distant 'office', which I was at this past weekend & have recently booted live medias there OK, but when attempting to change the new sticks' ownership on 3 PCs running 18.04.5 - no dice at any time or PC.
Hopefully this replies well enough to your anwering queries ??
I may be traveling there again after a couple of weeks depending upon the general world insanities, but not likely any sooner as it is a 2+ hour drive.
No idea how I might generally change how USB sticks mount unless via mount options in Disks - which has been said to defeat automounting - which is NOT OK for sticks inserted by my assistant & used for the backups there.
Thanks Again !!
Thanks. Considering the USB sticks are working fine in a "clean" environment - then that nicely confirms that it's just a configuration issue on the problematic install.
Obviously backing up and re-installing the OS is the cheap solution, but I suppose a first step is to clean up /etc/fstab by deleting lines referring to external drives that may have been added previously.
sudo pluma /etc/fstab
Please post the contents of this file if you need advise or not sure on what is safe to delete.
Even though this might have been advised previously, I would recommend not to change ownership if the sticks are formatted as FAT32 since the concept of permissions doesn't exist for this filesystem.
If you require memory sticks to never automatically mount, you can tell MATE to do so.
gsettings set org.mate.media-handling automount false
That would be better then manually specifying the options for each drive in the Disks utility.
2 Likes
Thanks Again Lah7.
Aside of entries for /boot, /, /home - all my fstab had were my 2 other partitions for storage & backups - then 3 other entries.
1 was for a USB stick, 1 for my external HDD, 1 for another disk I no longer use, so all are now commented out.
The only oddity was seeing /home marked as dirty, which I corrected.
After that editing...nothing has changed, sadly.
Given that I CANNOT change it anyhow - neither can I rename then unless I reformat them - and that I cannot change their perms either, this remains a null idea presently.
Ooopsy:
The exact opposite is actually needed;
They NEED to ALWAYS automount & as permissionlessly as possible, without delay !!
Given that in order for my backup system to work as desired, all sticks will be labeled identically - but:
That will not matter if this goofiness cannot be defeated.
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...?
I do have a tester NB with 20.04.x installed & I may find that & give it a try as well, if I have time later tonight...
Thanks in advance for any further assistance !!
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:
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.
2 Likes
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 !!
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.
2 Likes
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:
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 !!!
I am not sure this will help, but it would be worth a try.
Understanding File Permissions: What Does “Chmod 777” Mean?
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'.
1 Like
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.)
4 Likes
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)
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.
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:
-
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.
-
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=1000in 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)
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.
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.
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.
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.
Thanks again Lah7.
A stimulating exchange to be sure...and also somewhat circular as your most recent closing thought seems to indicate:
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.
1 Like
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.
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.