# [Solved] USB automount

## mark2

I have been able to manually mount usb devices by finding their /dev/sdXX in dmesg, but I don't want to have to go through this on every reboot. Does anyone have any suggestions on how to get usb devices detected automatically upon connecting to the pc?

Thanks in advance,

~Mark

----------

## VoidMage

Relevant solutions depend on your desktop env, as trying to do it in an agnostic way is significantly harder (barring trivial cases).

----------

## mark2

Doing an eselect kernel list shows:

```
eselect kernel list

Available kernel symlink targets:

  [1]   linux-3.2.12-gentoo *

  [2]   linux-3.3.8-gentoo
```

And the architecture is AMD64 (x86_64), and I am using a KDE desktop. I did not know that the kernel version had moved up. I may have to consider following that path; though it means going back through the documentation that has brought me this far. Is this of any benefit?

Thanks,

~Mark

----------

## NeddySeagoon

mark2,

We have already establised that your kernel and other low level bits and pieces are doing the right thing.

There is no need to update your kernel.

You just need a KDE user to point you in the right direction for how KDE does automounting but thats not me.

----------

## Randy Andy

But hopefully me (Neddy),

as i would like to try to help out, cause I'm using KDE.

I tried to find a precise documentation for that, but it seems to hard to cover only the automounting part, so i will try to give only the relevant steps here, let's hope that would be enought to get it work, mark2.

You don't need the latest kernel, but you have to ensure these kernel settings are done right:

```
CONFIG_USB_SUSPEND=y

CONFIG_IDE=n

CONFIG_AUDITSYSCALL=y
```

You have to set at least the following USE-Flags globally, if not done: udev udisks upower consolekit policykit (ntfs, if you want to mount ndtfs sticks too,).

Then recompile your system & world e.g. in this way (not the only one of course) 

```
emerge -DuvaN --keep-going system world && revdep-rebuild
```

Only if you're using ~arch, and you have sys-auth/polkit-0.106-r2 or higher installed, you have to do this afterwards:

```
usermod -d /var/lib/polkit-1 polkitd
```

Not necessary with sys-auth/polkit-0.105 or lower version (if you're on the stable arch)  :Wink: 

Put your user at least into this groups:

```
disk cdrom video cdrw usb messagebus  plugdev polkituser 
```

For the ntfs needed case, install sys-fs/ntfs3g, if not done by the dependency of the use flag.

Restart your system and try out. Beware also of the GUI settings of KDE regarding automount behaviour you can find here:

/Systemsettings/removable devices or media or however it's called on the English gui settings.

Hopefully I don't missed somthing, we'll see....

Much success, Andy.

----------

## NeddySeagoon

Randy Andy,

I was just going to watch and learn but you say 

 *Quote:*   

> Put your user at least into this groups: 
> 
> ```
> disk cdrom video cdrw usb messagebus  plugdev polkituser
> ```
> ...

 

No living user should ever be in the disk group.

```
 ls /dev/sd* -l

brw-rw---- 1 root disk 8,   0 Jun 23 12:34 /dev/sda

brw-rw---- 1 root disk 8,   1 Jun 23 12:34 /dev/sda1

brw-rw---- 1 root disk 8,   2 Jun 23 12:34 /dev/sda2

brw-rw---- 1 root disk 8,   4 Jun 23 12:34 /dev/sda4

brw-rw---- 1 root disk 8,   5 Jun 23 12:34 /dev/sda5

brw-rw---- 1 root disk 8,   6 Jun 23 12:34 /dev/sda6
```

Such users have raw access to your drives, so can do anything they want ... you would be as well writing your root password on the wall next to your keyboard.

If membership of the disk group is really required, something is very badly wrong with the method.

----------

## Randy Andy

Thanks Neddy,

that was a copy and paste error from my side, you are right of course.

So mark2, leave out this disk group, the rest should be correct, although I named more groups that are needed for automount purpose only, but nevertheless for KDE usage as far as i know.

So let's try it in this way.

----------

## mark2

Randy Andy, thanks for jumping in here.

On the first part with the CONFIG statements, do I type these in at the command line or do I go into the kernel menuconfig and do it there? (Sorry for such a newbie question, but I am literal as all hell.)

Then, I have on a stable arch:

```
equery --quiet list sys-auth/polkit

sys-auth/polkit-0.104-r1
```

I have no need for a ntfs case, so no problem.

@NeddySeagoon: No one other than myself uses this computer; my wife has her own, both a pc and a macbook, so she wouldn't touch a linux box  :Smile: . And while I know that "if it ain't broke, don't fix it", when something new comes out (like a new kernel version), the temptations are almost irresistible (shame on me). I will resist for now, however.  :Rolling Eyes: 

I'll wait to hear back before doing anything.

Thanks guys,

~Mark

----------

## Randy Andy

mark2

before configuring your kernel, you could try to check your actual settings e.g. with a syntax like this:

```
zgrep CONFIG_USB_SUSPEND /proc/config.gz 
```

Or check your /usr/src/linux/.config file with your preferred editor.

If everthing is adjusted right, then there is no need to change your kernel setting and to recompile it.

Otherwise yes, change your kernel setting with your preferred tool like menuconfig, nconfig or xconfig and do the appropriating steps afterwards.

Rest of your assumptions are right.

----------

## NeddySeagoon

mark2,

Groups and permissions serve several purposes.

1) they keep users apart and prevent them doing and seeing things they sould not.

2) they protect you from yourself.

Consider the following destructive command - don't do it, just folow the thought experiment.

First as root,

```
rm -rf /
```

attempts to remove every file on your system.

We all know that so we are careful not to do it. Now what does it do as a ordinary user?

The contents of /home/<user> will be removed along with any files owned by <user> in /tmp.

Other users won't even notice.

Users in the disk group can run low level commands like dd, fdisk and friends to write to your disks

You won't like that. They can't use mount but they have raw device access, so they can steal /etc/shadow, which holds all your user password hashes.

If you are in the disk group and get a dd command wrong as your normal user, you may not like it either, so it protects you from yourself.

The general lesson here is never operate with more permissions than you really need.

----------

## VoidMage

@NeddySeagoon: KDE still means udisks, so that whole fun with groups was redundant.

@mark2: what does 'udisks --mount' output for  the device in question ?

----------

## mark2

Sorry for the delay, guys. Had to do a little shopping with my wife.

At any rate, @Randy Andy, the zgrep command shows:

```
CONFIG_USB_SUSPEND=y, CONFIG_IDE is not set, and CONFIG_AUDITSYSCALL=y
```

@NeddySeagoon: I actually do understand Groups and Permissions, even though as an openSUSE user I was guilty of mostly running as root. And I probably caused myself a number of problems that way (it's kind of hard to break that habit when I work as IT support for a local school district using Windows and am used to running everything at "God level".). That said, I learned a long time ago not to to do a rm -rf / (and I threaten my co-workers with it every now and then  :Smile: ).

@VoidMage: udisks --mount for each device returns: /suchandsuch is not a block device: Resource temporarily unavailable.

So, ready to proceed?

~Mark

----------

## NeddySeagoon

mark2,

OMG! IT support for a local school district  ... kiddies are the worst group of hackers you can possibly encounter.

----------

## mark2

Neddy,

You are SO right! It's amazing with the stuff they come up with to circumvent your best efforts. Guess that's what keeps thing a bit interesting.   :Laughing: 

Actually, I am the District Webmaster, as well as a System Administrator and the senior member of my department, although I am not the boss. Which is probably a good thing.

Heh, heh,

~Mark

----------

## VoidMage

By 'device in question' I've meant any partition detected by kernel on that usb device.

----------

## mark2

@VoidMage:

I must not be doing something right but here's the output when I tried:

```
marktux / # udisks --mount sdb1

Cannot stat device file sdb1: No such file or directory

marktux / # udisks --mount sdc1

Cannot stat device file sdc1: No such file or directory

marktux / # udisks --mount --show-info /dev/sdb1

Cannot stat device file --show-info: No such file or directory

marktux / # udisks --show-info /dev/sdb1

Cannot stat device file /dev/sdb1: No such file or directory

marktux / # udisks --show-info /mnt/IOMEGA_HDD

Device file /mnt/IOMEGA_HDD is not a block device: Resource temporarily unavailable

marktux / # udisks --show-info /mnt/KINGSTON

Device file /mnt/KINGSTON is not a block device: Resource temporarily unavailable

marktux / # udisks --mount --show-info /mnt/IOMEGA_HDD

Cannot stat device file --show-info: No such file or directory
```

The mount points were directories I created to have someplace to point to. And I could browse the files within.

These are uncharted waters for me; I may need quite a bit of hand holding while I learn my way around.

Regards,

~Mark

----------

## NeddySeagoon

mark2,

```
udisks --mount /dev/sdb1
```

 might be better.

----------

## mark2

Unfortunately:

```
marktux / # udisks --mount /dev/sdb1

Cannot stat device file /dev/sdb1: No such file or directory
```

Regards,

~Mark

----------

## VoidMage

 :Evil or Very Mad:   :Rolling Eyes: 

When you plug the device in, if kernel detects anything of notice, it should be in dmesg (and/or in /proc/partitions).

'udisks --enumerate-device-files' should give you a big hint.

----------

## mark2

```
marktux / # udisks --enumerate-device-files

/dev/sda3

/dev/disk/by-id/ata-ST3160815AS_9RX23AE7-part3

/dev/disk/by-id/scsi-SATA_ST3160815AS_9RX23AE7-part3

/dev/disk/by-uuid/2a4059fa-06da-4a7f-a786-d1f5d114256a

/dev/disk/by-path/pci-0000:00:11.0-scsi-1:0:0:0-part3

/dev/sdc1

/dev/disk/by-id/usb-KINGSTON_DATA_TRAVELER_0195359860112-0:0-part1

/dev/disk/by-uuid/17E9-242F

/dev/disk/by-path/pci-0000:00:12.1-usb-0:2:1.0-scsi-0:0:0:0-part1

/dev/sda

/dev/disk/by-id/ata-ST3160815AS_9RX23AE7

/dev/disk/by-id/scsi-SATA_ST3160815AS_9RX23AE7

/dev/disk/by-path/pci-0000:00:11.0-scsi-1:0:0:0

/dev/sdd

/dev/disk/by-id/usb-HDS72251_6VLAT20_770000000006C419-0:0

/dev/disk/by-path/pci-0000:00:12.2-usb-0:1:1.0-scsi-0:0:0:0

/dev/sdc

/dev/disk/by-id/usb-KINGSTON_DATA_TRAVELER_0195359860112-0:0

/dev/disk/by-path/pci-0000:00:12.1-usb-0:2:1.0-scsi-0:0:0:0

/dev/sda1

/dev/disk/by-id/ata-ST3160815AS_9RX23AE7-part1

/dev/disk/by-id/scsi-SATA_ST3160815AS_9RX23AE7-part1

/dev/disk/by-uuid/87b90fcf-a133-4ae7-af39-23037f65eff5

/dev/disk/by-path/pci-0000:00:11.0-scsi-1:0:0:0-part1

/dev/sr0

/dev/disk/by-id/ata-ASUS_DRW-24B1ST

/dev/disk/by-path/pci-0000:00:11.0-scsi-0:0:0:0

/dev/sda2

/dev/disk/by-id/ata-ST3160815AS_9RX23AE7-part2

/dev/disk/by-id/scsi-SATA_ST3160815AS_9RX23AE7-part2

/dev/disk/by-uuid/361a4554-9458-4270-a836-8f9ef1787ffb

/dev/disk/by-path/pci-0000:00:11.0-scsi-1:0:0:0-part2

/dev/sdd1

/dev/disk/by-id/usb-HDS72251_6VLAT20_770000000006C419-0:0-part1

/dev/disk/by-uuid/1B0D-0B8F

/dev/disk/by-path/pci-0000:00:12.2-usb-0:1:1.0-scsi-0:0:0:0-part1
```

It seems to be giving me access to the flash drive, but not to the IOMEGA_HDD usb hard drive. I am not sure if this a time out issue or what.

~Mark

EDIT: Ok, I have rebooted and I now am able to access both usb drives without having to do anything manually. So, success on this one, I guess! I will consider this one solved. Thanks again for all the suggestions.  :Smile: 

~Mark

----------

