Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automount mounts in Read only #237

Closed
dmaahs2017 opened this issue Jan 12, 2022 · 15 comments
Closed

Automount mounts in Read only #237

dmaahs2017 opened this issue Jan 12, 2022 · 15 comments

Comments

@dmaahs2017
Copy link

dmaahs2017 commented Jan 12, 2022

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
Copy link
Owner

coldfix commented Jan 12, 2022

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
Copy link
Author

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. 😭

@coldfix
Copy link
Owner

coldfix commented Jan 12, 2022

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
Copy link
Author

dmaahs2017 commented Jan 12, 2022

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
Copy link
Author

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
Copy link
Author

[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
Copy link
Author

Gonna just format the drive and see if that fixes anything

@coldfix
Copy link
Owner

coldfix commented Jan 12, 2022

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
Copy link

dngray commented Feb 2, 2022

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
Copy link
Owner

coldfix commented Feb 2, 2022

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
Copy link

dngray commented Feb 2, 2022

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 added a commit that referenced this issue Feb 2, 2022
coldfix added a commit that referenced this issue Feb 2, 2022
@coldfix
Copy link
Owner

coldfix commented Feb 2, 2022

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
Copy link

dngray commented Feb 2, 2022

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
Copy link
Owner

coldfix commented Feb 2, 2022

Unrelated. Probably same as #220.

@coldfix
Copy link
Owner

coldfix commented Feb 2, 2022

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

@coldfix coldfix closed this as completed Feb 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants