Automount mounts in Read only

[dmaahs2017]

I have a vfat USB. Running Arch + Bspwm

When udiskie automounts it, the filesystem is read only.

I started udiskie with the -s option, and have not created a custom config file. udiskie -s

When I mount the USB like so usdisksctl mount -b /dev/sdc1 -o rw it works fine.

This may just be a user error. But any support would be much appreciated. I search for 3 hours, and didn't find many useful threads or wikis.

[coldfix]

Hi,

try creating a config file at ~/.config/udiskie/udiskie.yml with something like this in it:

device_config:
- id_type: vfat
  options: [rw]

This may just be a user error. But any support would be much appreciated. I search for 3 hours, and didn't find many useful threads or wikis.

sorry, I really ought to improve documentation, but not seeing it happen soon. Any PRs of course appreciated.

[dmaahs2017]

In that you have -id_type: vfat. Is there a way to configure it as read/write for all types of file systems? As the default?

Usb's in arch have been my bane so far. :sob:

[coldfix]

As default for all FS:

device_config:
- options: [rw]

(but usually always get rw by default anyway except NTFS, so it's a bit weird that it's not the case for you)

[dmaahs2017]

Actually it's really weird. I'll mount it with udisks. check with mount and it will be rw. Then 15 minutes later it will be ro... No idea what is happening

[dmaahs2017]

Think I may have figured it out

/dev/sdc1 on /run/media/dalton/8CA9-EE03 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

erorrs=remount-ro. So there is probably some error, then it gets set to Read only.

I would like it to remount-rw on errors. I know that this likely has nothing to do with your utility now, but help would be appreciated.

[dmaahs2017]

[12345.027419] FAT-fs (sdc1): error, clusters badly computed (47225 != 47101)
[12345.027424] FAT-fs (sdc1): Filesystem has been set read-only
[12345.028824] FAT-fs (sdc1): error, clusters badly computed (47226 != 47102)
[12345.030119] FAT-fs (sdc1): error, clusters badly computed (47227 != 47103)

Yep, looks like theres some underlying issue. Found this on dmesg after it swapped to read only

[dmaahs2017]

Gonna just format the drive and see if that fixes anything

[coldfix]

I would like it to remount-rw on errors. I know that this likely has nothing to do with your utility now, but help would be appreciated.

man mount gives -o errors=continue. But not sure that's a good idea. Definitely not as default. Also it's quite possible that udisks doesn't accept this flag from the user.

Gonna just format the drive and see if that fixes anything

Good luck!

[dngray]

For some reason I'm having trouble with udiskie opening my container as read only.

1. My udiskie.yml config is:

   device_config:
   options: [rw]

2. Created a test volume:

   ~> dd if=/dev/random of=test count=100000 bs=1000
   ~> cryptsetup luksFormat test
   ~> sudo cryptsetup luksOpen test testvol
   ~> sudo mkfs.ext4 /dev/mapper/testvol
   ~> sudo cryptsetup luksClose testvol

3. Mount with udiskie-mount:

   ~> udiskie-mount -o options=rw test
   set up test as /dev/loop0
   Enter password for /dev/loop0:
   unlocked /org/freedesktop/UDisks2/block_devices/loop0

4. Check info with udisksctl:

   ~> udisksctl info -b /dev/mapper/luks-86f4d3c9-c37e-4d87-86df-a0bfdce861a7
   /org/freedesktop/UDisks2/block_devices/dm_2d1:
    org.freedesktop.UDisks2.Block:
      Configuration:              []
      CryptoBackingDevice:        '/org/freedesktop/UDisks2/block_devices/loop0'
      Device:                     /dev/dm-1
      DeviceNumber:               64769
      Drive:                      '/'
      HintAuto:                   false
      HintIconName:
      HintIgnore:                 false
      HintName:
      HintPartitionable:          false
      HintSymbolicIconName:
      HintSystem:                 true
      Id:                         by-id-dm-name-luks-86f4d3c9-c37e-4d87-86df-a0bfdce861a7
      IdLabel:
      IdType:                     ext4
      IdUUID:                     94cb3695-ca48-4564-a97a-f32a211c25ef
      IdUsage:                    filesystem
      IdVersion:                  1.0
      MDRaid:                     '/'
      MDRaidMember:               '/'
      PreferredDevice:            /dev/mapper/luks-86f4d3c9-c37e-4d87-86df-a0bfdce861a7
      ReadOnly:                   true
      Size:                       83222528
      Symlinks:                   /dev/disk/by-id/dm-name-luks-86f4d3c9-c37e-4d87-86df-a0bfdce861a7
                                  /dev/disk/by-id/dm-uuid-CRYPT-LUKS2-86f4d3c9c37e4d8786dfa0bfdce861a7-luks-86f4d3c9-c37e-4d87-86df-a0bfdce861a7
                                  /dev/disk/by-uuid/94cb3695-ca48-4564-a97a-f32a211c25ef
                                  /dev/mapper/luks-86f4d3c9-c37e-4d87-86df-a0bfdce861a7
      UserspaceMountOptions:      uhelper=udisks2
    org.freedesktop.UDisks2.Filesystem:
      MountPoints:        /run/media/dngray/94cb3695-ca48-4564-a97a-f32a211c25ef
      Size:               83222528

5. polkit.service is running:

   ~> systemctl status polkit.service
   ● polkit.service - Authorization Manager
       Loaded: loaded (/usr/lib/systemd/system/polkit.service; static)
       Active: active (running) since Wed 2022-02-02 03:05:46 UTC; 3h 7min ago

6. lxqt-policykit-agent is running.

7. The udiskie policy kit rules are present.

8. It doesn't seem to be the mounting, either because if i try to mount the volume:

   ~> sudo mount /dev/mapper/luks-86f4d3c9-c37e-4d87-86df-a0bfdce861a7 ~/mount/usb/
   mount: /var/home/dngray/mount/usb: WARNING: source write-protected, mounted read-only.

9. My user is in the storage group:

   ~> id
   uid=1000(dngray) gid=1000(dngray) groups=1000(dngray),10(wheel),1001(storage) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[coldfix]

Hi,

thanks for your input.

dd if=/dev/random of=test count=100000 bs=1000
cryptsetup luksFormat test
sudo cryptsetup luksOpen test testvol
sudo mkfs.ext4 /dev/mapper/testvol
sudo cryptsetup luksClose testvol

Your case is a bit different, because you're working with a loop device. I can reproduce this example and have a fix for it. It boils down to the fact that udiskie currently doesn't bother with the read_only argument of the Mounter.losetup(...) call (also: the open mode needs to be set to O_RDWR in that case).

Was the loop device the original scenario in which your problem occurred, or just a believed minimal-working-example?

It doesn't seem to be the mounting, either because if i try to mount the volume:

~> sudo mount /dev/mapper/luks-86f4d3c9-c37e-4d87-86df-a0bfdce861a7 ~/mount/usb/
mount: /var/home/dngray/mount/usb: WARNING: source write-protected, mounted read-only.

Yeah, that's because, currently, udiskie always sets up the loop device as readonly.

My udiskie.yml config is:

device_config:
options: [rw]

Just FYI, this is not causing the problem in your example, but: device config is a list, and options are given in rule entries, so there is a - missing:

device_config:
- options: [rw]

[dngray]

thanks for your input.

dd if=/dev/random of=test count=100000 bs=1000
cryptsetup luksFormat test
sudo cryptsetup luksOpen test testvol
sudo mkfs.ext4 /dev/mapper/testvol
sudo cryptsetup luksClose testvol

Your case is a bit different, because you're working with a loop device. I can reproduce this example and have a fix for it. It boils down to the fact that udiskie currently doesn't bother with the read_only argument of the Mounter.losetup(...) call (also: the open mode needs to be set to O_RDWR in that case).

Was the loop device the original scenario in which your problem occurred, or just a believed minimal-working-example?

I actually do have some LUKS containers like above that I use for storing various keyfiles etc.

My udiskie.yml config is:

device_config:
options: [rw]

Just FYI, this is not causing the problem in your example, but: device config is a list, and options are given in rule entries, so there is a - missing:

device_config:
- options: [rw]

Ah thanks for spotting that. In any case I think your above explanation is quite likely because I also tried with -o options=rw which should override any configuration file. I also named it wrong, it should be called config.yml.

If the fix is easy that'd be really cool as udiskie is a nice little portable program for this purpose.

[coldfix]

If the fix is easy that'd be really cool as udiskie is a nice little portable program for this purpose.

a quick-and-dirty fix itself is relatively easy. Making it configurable (whether rw/ro should be used) is more effort. So that'll probably take a while, but I can for now release a version that will make RW the default if sufficient permissions are available.

[dngray]

I wonder if this is related?

> udiskie-mount -v /dev/nvme0n1p3
DEBUG [2022-02-02 23:46:08,469] udiskie.udisks2: Daemon version: 2.9.4
DEBUG [2022-02-02 23:46:08,469] udiskie.udisks2: Keyfile support: True
DEBUG [2022-02-02 23:46:08,508] udiskie.config: new rule: {} -> {options=['rw']}
DEBUG [2022-02-02 23:46:08,508] udiskie.config: new rule: {symlinks=/dev/mapper/docker-*} -> {ignore}
DEBUG [2022-02-02 23:46:08,509] udiskie.config: new rule: {symlinks=/dev/disk/by-id/dm-name-docker-*} -> {ignore}
DEBUG [2022-02-02 23:46:08,509] udiskie.config: new rule: {is_loop, !is_ignored, loop_file=/*} -> {!ignore}
DEBUG [2022-02-02 23:46:08,509] udiskie.config: new rule: {!is_block} -> {ignore}
DEBUG [2022-02-02 23:46:08,509] udiskie.config: new rule: {!is_external, is_toplevel} -> {ignore}
DEBUG [2022-02-02 23:46:08,509] udiskie.config: new rule: {is_ignored} -> {ignore}
DEBUG [2022-02-02 23:46:08,510] udiskie.udisks2: found device owning "/dev/nvme0n1p3": "/org/freedesktop/UDisks2/block_devices/nvme0n1p3"
DEBUG [2022-02-02 23:46:08,511] udiskie.config: /dev/nvme0n1 matched {!is_external, is_toplevel} -> {ignore}
WARNING [2022-02-02 23:46:08,511] udiskie.mount: not unlocking /org/freedesktop/UDisks2/block_devices/nvme0n1p3: unhandled device

In this case I was trying to decrypt my 3rd partition on my NVMe.

[coldfix]

Unrelated. Probably same as #220.

[coldfix]

Closing this since the original issue was probably due to faulty device.