I just noticed that after mounting an SD card all files and dirs in it are with 700 permissions which is wrong (a PDF is not executable). IIRC it wasn’t like that before.
What could be the reason for this change and how can I set default permissions for removable storage?
How did you mount?
Can you show us relevant output from the following?
mount|grep sd
dir /media
I simply inserted the SD card in the USB card reader and KDE shows it in Dolphin.
It gets mounted in /run/media/<myusername>/EOS_DIGITAL
Ok, so Udisks/desktop mounted.
Please at least show us some definitive output…
mount|grep sd
dir /run/media/<myusername>
I can not reproduce this on my Leap 42.3 system. The bits set are rw-r–r-- (as it was on earlier openSUSE versions).
So why is it different at your’s?
While I admit that a desktop mount should not set any x-bits (for security reasons, do not execute a file from an external, untrusted source), I think your talking about PDF files has no ground. The mount is really not going to check the contents of all files to find out if setting an x-bit might be useful.
We don’t even know what the file system on the SD card is. F.e. FAT cannot write linux permissions, and FAT is what lots of cameras ( EOS = Canon ) use/used.
Which is one of the reasons I requested the output of mount. Vague descriptions with out all the necessary supporting definitive information leads to speculation.
The 2 entries which appear in the command’s output after mounting the SD card are:
/dev/sdf1 on /run/media/<myusername>/EOS_DIGITAL type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
/dev/sdf1 on /var/run/media/<myusername>/EOS_DIGITAL type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
~]: dir /run/media/$USER
total 256
drwx------ 1 <myusername> users 262144 Jan 1 1970 EOS_DIGITAL
That’s what I am trying to find too. Which is even more interesting - I noticed this just recently. Previously (think months and years) it was not like that. FWIW in .bashrc I have ‘umask 0077’ but it has always been like that, so that is not something new or recently changed.
While I admit that a desktop mount should not set any x-bits (for security reasons, do not execute a file from an external, untrusted source), I think your talking about PDF files has no ground. The mount is really not going to check the contents of all files to find out if setting an x-bit might be useful.
I mentioned PDF just to say that it is regardless of file type, just like you explained.
It is a 32GB SD card formatted inside the Canon camera. mount and ‘df -T’ show that type is fuseblk.
fuseblk is not the file system. Mount the card manually on /mnt as root, the run
mount | grep sd
again and show the output. Another thing I see is that the date is Jan 1st 1970 …
I used ‘sdf’ instead of ‘sd’ for grep filtering because there are quite a few HDD partitions starting with sd*
As far as I see the FS is exfat. (the card is in write protected mode, so the other message is correct)
~]: mount | grep sdf
/dev/sdf1 on /run/media/<myusername>/EOS_DIGITAL type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
/dev/sdf1 on /var/run/media/<myusername>/EOS_DIGITAL type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
~]: su -
Password:
# umount /dev/sdf1
# mount | grep sdf
# mount /dev/sdf1 /mnt
FUSE exfat 1.2.7
WARN: '/dev/sdf1' is write-protected, mounting read-only.
# mount | grep sdf
/dev/sdf1 on /mnt type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
#
After that /mnt and all files and dirs in it are with permissions 777 and ownership root:root.
I noticed that too. But the files and dirs inside the mount dir are with correct timestamps.
Ah ha!
Be that as it may, the bottom line is, exFAT is not a UNIX®-like file system and therefore, doesn’t understand the UNIX® and, anything that looks or smells like UNIX®, file system attribute bits – the things which make our life much easier, more productive and more secure …
[HR][/HR]Therefore, my suggestion is, given a “modern” UNIX®-like system – the thing we call “Linux” – forget the things we did years ago on UNIX® systems such as setting umask bits in the shell initialisation files, and simply use the more modern things such as FUSE “as is”, given that we currently rely on other system mechanisms such as “Authorization Manager” (for example ‘polkit’) to deal with system security issues …
I have no idea how to use this info. Can you explain please?
As I said - previously I haven’t seen such issue, I noticed it just recently. The last time I mounted this same card was in December and I didn’t see such weird permissions. So I am not quite sure it is an issue with exfat itself. But I am not an expert.
Since manual mounting results in “normal” permissions, I’d say this is a bug.
Ok, I reported it. Any idea for a workaround?
No. The one thing I can think of, is to try if the issue is the same for a newly created user.
Taking a SanDisk Extreme Pro 32 GB SD card formatted in a Sigma sd Quattro and plugging it into a Hama USB 3.0 Card Reader, with a KDE Plasma 5 desktop and the “normal” (for KDE) access via the Device Notifier – “Open with File Manager”, I get the following results:
Mount:
/dev/sdj1 on /var/run/media/xxx/SD QUATTRO type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)
> cd /var/run/media/xxx/SD\ QUATTRO/
>
> ls -la
total 96
drwxr-xr-x 4 xxx users 32768 1. Jan 1970 ./
drwxr-x---+ 3 root root 60 13. Apr 18:13 ../
drwxr-xr-x 3 xxx users 32768 8. Mär 2017 DCIM/
drwxr-xr-x 2 xxx users 32768 13. Mai 2017 MISC/
> ls -la ..
total 32
drwxr-x---+ 3 root root 60 13. Apr 18:13 ./
drwxr-xr-x 3 root root 60 13. Apr 18:09 ../
drwxr-xr-x 4 xxx users 32768 1. Jan 1970 SD QUATTRO/
>
I do not set ‘umask’ in my ‘.profile’ and, I haven’t changed the default system setting …
[HR][/HR]My 64 GB card is exFAT and I read it via my QNAP NAS (also a Linux) – exFAT license paid …
It may be that, the Linux FUSE exFAT driver also got updated recently which may, therefore, be the cause, possibly …
When I tested I used 2 different 256GB PNY SD XC Class 10 cards and a Transcend TS-RDF8K USB 3.0 card reader.
What result do you get with your 64Gb (exfat) card?
Given a different (QNAP) system (ARM CPU … ) and, an official, licensed, exFAT driver – possibly the same one as that used by the automotive industry but, don’t really know …
SanDisk Extreme PRO 64 GB formatted in the Sigma sd Quattro:
Mount:
/dev/sdd1 on /share/external/DEV3301_1 type ufsd (rw,iocharset=utf8,dmask=0000,fmask=0111,force)
[/etc] # cd /share/external/DEV3301_1/
[/share/external/DEV3301_1] # ls -al
drwxrwxrwx 1 admin administ 131072 Jun 16 2017 DCIM/
drwxrwxrwx 1 admin administ 131072 Jun 16 2017 MISC/
drwxrwxrwx 1 admin administ 131072 Jun 16 2017 System Volume Information/
[/share/external/DEV3301_1] # ls -al ..
drwxr-xr-x 3 admin administ 60 Apr 13 19:25 ./
drwxrwxrwt 5 admin administ 280 Apr 13 19:25 ../
drwxrwxrwx 1 admin administ 131072 Apr 13 19:25 DEV3301_1/
[/share/external/DEV3301_1] #
~] # uname -a
Linux YYY 4.2.8 #2 SMP Sat Mar 31 04:29:41 CST 2018 armv7l unknown
~] #
Annapurna Labs Alpine AL212 Dual-core ARM Cortex-A15 CPU @ 1.70GHz
QNAP Firmware version: 4.3.4.0537 Build 201803
Your mount points are different. I suppose the mounting process is also different on your system, no?
Fine, but umask 0077 basically means that file permissions will be 700, exactly like you’ve reported. If this was not the case earlier, then it now looks more like a fixed bug to me.