Problems with mounting RW FAT32 filesystem on LEAP 42.1

English Hardware
1

I am a long standing Opensuse User and one thing I have always had persistent problems with is automounting my Backup drive with Read write permissions within a normal user session. This is a drive I hold most of my music collection on and one which I share over a SAMBA share and is formatted to FAT32. Its always been a pain to mount this drive such that the USER can write to it - but since a recent reinstall of Gnome LEAP 42.1 it seems | cannot get it to work at all.

I have tried all options using Gparted, Yast Partitioner and Gnome DISK.
I have tried logging in as root and changing the drive permissions, but even the root account is blocked from changing the file permissions. I suspect this is because of the way ownership is allocated at boot as a virtual ownership rather than a fixed real ownership.
I have also tried editing the Fstab file directly but none of the options that traditionally work do anything but make Gnome crash on startup. Adding USERS and/or USER to the Fstab simply crashes it. I have tried using all the old threads for guidance - but they all seem outdated and not any longer functional. I have tried the options discussed in this guide for LEAP, but it just hangs the system:

https://tweakhound.com/2015/11/10/opensuse-leap-42-1-tips-tricks-and-tweaks/

I can only assume that these incompatibility issues are due to the automount procedure - but I am surprised that I cannot get it to work through the fstab file.

I have previously got things working by creating a directory owned by the user account and then mounting to this directory - but cannot for the life of me find the guide I used to do this with.

Opensuse has always had an over-zeaolous application of security prermissions for a user friendly desktop experience, and this is starting to bug me that every time I update my system this seemingly simple operation seems to take days to resolve.

Stephen

2

Show /etc/fstab

3

Here it is:

/dev/disk/by-id/ata-ST3500418AS_6VMCDBDJ-part3 swap swap defaults 0 0
/dev/disk/by-id/ata-ST3500418AS_6VMCDBDJ-part2 / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-ST3500418AS_6VMCDBDJ-part4 /boot/efi vfat umask=0002,utf8=true 0 0
/dev/disk/by-uuid/16c3ea1b-4176-4520-b14c-0d0648618316 /mnt/16c3ea1b-4176-4520-b14c-0d0648618316 auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/468914e0-6a99-46e6-b77e-8ae14e096ae6 /mnt/468914e0-6a99-46e6-b77e-8ae14e096ae6 auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/4A9E-89E8 /mnt/4A9E-89E8 auto nodev,nofail,x-gvfs-show 0 0

The parts in red are the relevant ones which are autogenerated.

Stephen

4

OK I resolved this using this guide:

https://en.opensuse.org/SDB:Access_your_Windows_files

However the exact line suggested

utf8,codepage=850,dmask=000,fmask=111,shortname=winnt

Didn’t work without dropping the last bit of the line which is in red.
Instead of using Yast>System>partitioner, I used the DISKS utility
The options I used were :
Automatic Mount Options >OFF
Mount at startup TICKED
Show in user interface TICKED
In the unlabelled box under symbolic icon name I inserted :

codepage=850,utf8,dmask=000,fmask=111,x-gvfs-show

The mount point for me was “/mnt/4A9E-89E8” but could be anything after the /mnt/
This generates Identify As “/devb/disk/by-uuid/4A9E-89E8”
File system type > vfat

Hope that helps.

Stephen

5

I spoke to soon. Whatever I did solved my original problem but as a side benefit broke my SAMBA share. I attempted to restore SMB functionality by copying a smb.conf file from a cloned version of my main system of about a fortnight ago, didn’t work. Samba is working and shows up the share for all the other three computers on the network - but the main computer which hosts the samba server resolutely refuses to show up. Can’t get Nautilus share to create a share as it fails with the

‘net usershare’ returned error 255: net usershare add: cannot convert name “Everyone” to a SID. The connection was refused. Maybe smbd is not running.

Gnome frequently hangs at boot up and crashes out as it waits for an interminable amount of time to launch the samba services - without success.

In all the time I have used Suse I have been lucky to get SAMBA to work stably for more than a week at a time. It seems to be a horribly neglected and grossly buggy aspect of Linux and frankly the developers don’t seem to give a **** about making sure that this essential part of home computing works reliably.
Its little wonder that most people refuse to consider Linux as a viable alternative to Windows when basic functionality like getting access to disks, bluetooth, samba seem to be in a state of perpetual flux and brokenness. Linus Torvid is right when he says that the desktop experience in Linux is terrible and broken.

Stephen

6

Well, for a start, I would suggest that you should change that resource from FAT32 to NTFS, then continue from there.

7

Thats not a very helpful suggestion at all, and the sort of comment that gets Linux a very bad name. The operating system is there to serve the user not the other way round.

…

I decided to take a look at the Samba logs to see what was going on. Came across this :

[2016/08/17 22:01:24, 0] …/lib/util/util.c:285(directory_create_or_exist_strict)
invalid permissions on directory ‘/var/log/samba/cores’: has 0755 should be 0700

There were a few other files with the wrong permissions related to
Chmod’ed the permission and the computer magically appeared.

Stephen

8

NTFS is a Windows file system and can only be used with a kludge since it does not properly store Linux permissions so they are faked when you mount. adding user to the parameters may help. As written the partition will mount with root permissions

Please read man mount for a better understanding

9

It seems that if you set it to automount at bootup using Disks, or one of the other tools, then it allocates Root privileges and only allows read access to the user.
If you set it to mount when the user clicks on it in Nautilus, then it remains as owner Root but grants the User privileges once the user has entered the administrator password at the point of mount. This is just about useful - but for a single user desktop its rather inconvenient to demand the Administrator password to access a permanently fixed harddrive. I suspect that there must be some option which relaxes these requirements with automount but the documentation for the procedure for mounting FAT and NTFS file systems is patchy.
As it is the solution I pointed to in post four is working as I want it with rw access automatically at bootup and no user intervention necessary. Its not the way Leap wants to do it out of the box but its supported.

I don’t know when exactly the problem with Samba crept in and might be associated with a security update. However I never changed the permissions on those files and Samba suddenly decided that not having the correct permissions was critical to operation (when it never did before), so I suspect it was a deep “housekeeping” bug which only surfaced unexpectedly as a byproduct of some other change. It may turn out to have been the root of many of my previous Samba problems but which I managed to work around without correcting the underlying problems previously.

I suspect that all of this will rear its ugly head again when I upgrade to Leap 42.2. Its my experience that obscure bugs can linger for years without resolution, a typical example been Bluetooth filesharing which is only slightly more usable in LEAP over all previous versions of Opensuse I have used (ie still broken but just about usable with knowledge and perseverance).

It might be worth me considering a move over to SLE for a more stable experience.

Stephen

10

On Thu 18 Aug 2016 12:36:01 PM CDT, Shoog wrote:

gogalthorp;2789489 Wrote:
> NTFS is a Windows file system and can only be used with a kludge since
> it does not properly store Linux permissions so they are faked when
> you mount. adding user to the parameters may help. As written the
> partition will mount with root permissions
>
> Please read man mount for a better understanding

It seems that if you set it to automount at bootup using Disks, or one
of the other tools, then it allocates Root privileges and only allows
read access to the user.
If you set it to mount when the user clicks on it in Nautilus, then it
remains as owner Root but grants the User privileges once the user has
entered the administrator password at the point of mount. This is just
about useful - but for a single user desktop its rather inconvenient to
demand the Administrator password to access a permanently fixed
harddrive. I suspect that there must be some option which relaxes these
requirements with automount but the procedure for mounting FAT and NTFS
file systems is patchy.
As it is the solution I pointed to in post four is working as I want it
with rw access automatically at bootup and no user intervention
necessary. Its not the way Leap wants to do it out of the box but its
supported.

I don’t know when exactly the problem with Samba crept in and might be
associated with a security update. However I never changed the
permissions on those files and Samba suddenly decided that not having
the correct permissions was critical to operation (when it never did
before), so I suspect it was a deep “housekeeping” bug which only
surfaced unexpectedly as a byproduct of some other change. It may turn
out to have been the root of many of my previous Samba problems but
which I managed to work around without correcting the underlying
problems previously.

I suspect that all of this will rear its ugly head again when I upgrade
to Leap 42.2. Its my experience that obscure bugs can linger for years
without resolution, a typical example been Bluetooth filesharing which
is only slightly more usable in LEAP over all previous versions of
Opensuse I have used (ie still broken but just about usable with
knowledge and perseverance).

It might be worth me considering a move over to SLE for a more stable
experience.

Stephen

Hi
I have no issues mounting vfat usb devices under GNOME as my user, so
your adding via fstab?

I just plug them in and all is good, why all the nofail, gvfs in your
fstab?


/dev/sde1 on /run/media/username/A0B8-3352 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,uhelper=udisks2)

Have you tried letting YaST partitioner do it’s thing to create the
mount point if you want to attach permanently?

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.27-27-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

11

Have you tried letting YaST partitioner do it’s thing to create the
mount point if you want to attach permanently?

–

Its YAST partitioner which creates the “dodgy” mount options which caused all the issues in the first place. It only seems to effect fixed disks (mine using SATA) as like you I have no issues plugging in a USB stick and it working as needed straight out of the box - so they must handle USB’s differently to fixed SATA drives.

Stephen

12

Not sure why you are running into this problem, then, if you used the Yast partitioner to set the mount point. I always have an NTFS partition on my various machines that is automounted at startup and usually works just fine.

Yes, if you as a User try to manually mount it, without defining the mount options, then you will need root privileges (ie: You will be asked for root password.) to mount it. The permissions are then set, though, to give the User who mounts it access.

Remember, these are virtual permissions assigned by Linux to keep the NTFS system safe & under control. The NTFS permissions on the files cannot be translated to Linux efficiently, as they are not the same at all.

You therefore would need to properly define the faked permission settings in your fstab, and you should read the manual (I detest saying that! ;)) to see what options are available to you. That way you can choose exactly how you want it to mount and run.

As for FAT32: Why? NTFS is much more capable with files and structure. In the earlier post, I was not telling you that you must switch to it, just that it would be more usefull and workable.