My system has developed a strange defect after a distribution upgrade (OpenSuSE 12.3 -> 13.2). I have various USB devices that I want to mount to different top-level directories: the backup drive to /backup, my USB stick to /usb, and the SD card adapter to /SD. That used to work without problem by simply naming the device ID and the top-level directory in /etc/fstab:

/dev/disk/by-id/scsi-1TOSHIBA_TransMemory-part1                        /usb       vfat     noauto,user,exec               0 0
/dev/disk/by-id/ata-ST2000LM003_HN-M201RAD_S34RJ9AFA36173-part1        /backup    ext4     noauto,user,exec               0 0
/dev/disk/by-id/usb-Generic-_SD_MMC_MS_PRO_20120926571200000-0:0-part1 /SD        exfat    noauto,user,exec  

Now, with the new kernel (3.16.7) and all, the exact /dev/disk/by-id identifiers have changed, so I adapted them, but mounting fails nevertheless. It turns out I can mount none of these devices to their preferred mount points anymore, not even when I give the real name (e.g., /dev/sdc1 or the like). Mounting them manually, even as root, gives no output and returns 0 just like a normal mount, but it doesn't populate the moint point with the content of the disk, and in fact the mount command claims that the device isn't mounted after all.

However, I can mount any of these devices successfully if I choose the mount point /mnt, or, weirdly, a subdirectory of /mnt. That's reassuring - it proves that there isn't a hardware or driver problem - but I'd really like to mount my peripherals to their mnemonic names, and in particular I'd sometimes like to mount two of them simultaneously.

Why on Earth would the system care where I mount something, as long as the mount point exists, is accessible, and isn't already mounted? All three top-level dirs worked fine under the old kernel (3.7.10), and now they don't. Can I be running into some new security manager or filter rule that I've never heard about?

  • You should run the mount command under strace to see what it is doing and file a bug report with OpenSuSE including that information. – psusi Feb 23 '16 at 2:09
  • @psusi I have run mount under strace, and the output seems identical (excluding different addresses being returned for allocations), right until the exit with code 0. That's why I assume that there's some other (perhaps auto-mounting?) functionality interfering with my manual mount command that I don't even know about. – Kilian Foth Feb 23 '16 at 7:12
  • May that be the case because of your fstab being broken ? I see missing information... – gerhard d. Feb 23 '16 at 11:28
  • Yikes! I can't remember whether those trailing numbers are actually missing, or whether I just mispasted. I'll have to check when I get home. Could a broken fstab cause this? And why would /mnt still work - is there a hardcoded exception for that somewhere? – Kilian Foth Feb 23 '16 at 11:34
  • If this may help: I run opensuse 13.1, kernel 3.11.10, and I can manually mount /dev/sda1 to /windows . Maybe try other kernel flavors? (I use the -desktop one.) – L. Levrel Feb 23 '16 at 12:25

I have it!

It's AppArmor, which SuSe Linux now activates by default. It's supposed to add capability-driven security on top of the traditional permissions-based security model, and in its default configuration it disallows all mounts except very specifically described ones, among them /mnt. Once I got rid of AppArmor, my mounts work normally.


I can't answer your underlying question, but I can offer you a workaround.

  1. Create a set of subdirectories under /mnt, one per device.
  2. Replace each "real" and preferred directory, eg /usb, with a symlink to the relevant directory under /mnt
  3. Fix up /etc/fstab correspondingly.

Not ideal but it will get you back up and running while you look for a true solution

  • 1
    I thought of that, but I'd like to understand what's going on. I thought using /mnt for mounting things was a pure matter of convention and technically as good as any other path. What kind of system component might treat /mnt different from other values? I haven't found anything in my /etc. – Kilian Foth Feb 23 '16 at 12:33
  • 1
    @Kilian, SElinux, perhaps? – roaima Feb 23 '16 at 13:21
  • Would SElinux confess it to me when it prevents things it considers unsafe, or is that classified information? 'Cause I'm not seeing any trace of it in /var/log/messages. – Kilian Foth Feb 23 '16 at 13:24
  • @Kilian sorry, but I don't know. – roaima Feb 23 '16 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.