Bug 1001554 - A user cannot umount devices that are not in /etc/fstab
A user cannot umount devices that are not in /etc/fstab
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: GNOME
Current
Other Other
: P5 - None : Normal with 3 votes (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-09-28 01:15 UTC by Ronan Chagas
Modified: 2017-01-02 23:07 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
dimstar: needinfo? (ronisbr)


Attachments
udiskctl dump (24.14 KB, text/plain)
2016-09-28 22:46 UTC, Ronan Chagas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ronan Chagas 2016-09-28 01:15:01 UTC
Hi guys!

After the update of Tumbleweed to GNOME 3.22, a user cannot umount a FAT32 USB stick using files. It shows the message:

umount: /run/media/ronan.arraes/RONAN: umount failed: Operation not permitted

Hence, the only way I found to umount the device was logging as root.

I tried with an external HDD that has two partition: one FAT32 and another EXT4. The latter can be correctly umount by a user using Files, whereas the former cannot. This problem was not happening with GNOME 3.20.

I could reproduce this behavior in two different Tumbleweed machines. Hence, it should not be a configuration problem.

More information about my system:

cat /etc/os-release                                               22:14:32 
NAME="openSUSE Tumbleweed"
# VERSION="20160924"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="20160924"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20160924"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
Comment 1 Ronan Chagas 2016-09-28 01:43:32 UTC
Actually, I will change the title of the bug. It turns out that every EXT4 device that I used had an entry in /etc/fstab. When I remove that entry, then I also could not umount the device using Files.

Hence, the bug is now related to every device that has not an entry in /etc/fstab. When I added the FAT32 USB stick to /etc/fstab, then I could umount it using Files.
Comment 2 Ronan Chagas 2016-09-28 22:46:47 UTC
Created attachment 694865 [details]
udiskctl dump
Comment 3 Ronan Chagas 2016-09-28 22:47:29 UTC
zaitor asked me to attach the log of `udiskctl dump`. In this case, the device I cannot unmount is /dev/sdb1
Comment 4 Ronan Chagas 2016-09-28 22:56:35 UTC
I see these messages in journald log every time I hit the eject button in Files (nautilus):

set 28 19:54:30 ronanarraes-osn tracker-extract[2639]: Unmount operation failed, adding back mount point...
set 28 19:54:30 ronanarraes-osn tracker-miner-f[2645]: Unmount operation failed, adding back mount point...
Comment 5 Ronan Chagas 2016-09-29 03:24:56 UTC
By the way, I can't even eject my DVD, because I can't unmount it. Now, I need to unmount as root, and then hit the eject button in nautilus.
Comment 6 Ronan Chagas 2016-09-29 03:52:14 UTC
Guys,

I found something really weird. I cannot use `umount` as user to unmount the device. However, if I run the following command as an user:

udisksctl unmount -b /dev/sdb1

then the device is unmounted properly.
Comment 7 Dominique Leuenberger 2016-09-29 06:50:29 UTC
(In reply to Ronan Chagas from comment #6)
> Guys,
> 
> I found something really weird. I cannot use `umount` as user to unmount the
> device. However, if I run the following command as an user:
> 
> udisksctl unmount -b /dev/sdb1
> 
> then the device is unmounted properly.

nothing weird - normal behavior; but udisk is what nautilus should fire off to do the umount too (well, through the dbus api)
Comment 8 Ronan Chagas 2016-09-29 13:11:30 UTC
I tested with nemo and I saw exactly the same error message.
Comment 9 Ronan Chagas 2016-10-01 18:42:11 UTC
I formatted my computer and installed Tumbleweed from the latest snapshot. I login in GNOME for the first time and tried to plug and unmount an USB stick. The same problem occurred.

I formatted again, but this time installing XFCE, and I also see the same problem. Hence, it should be something with gvfs I think.
Comment 10 Ronan Chagas 2016-10-01 18:52:32 UTC
Just one more information, in KDE it works perfectly. I can unmount the device using dolphin for example.
Comment 11 Ronan Chagas 2016-10-02 15:27:37 UTC
And now the things become really weird, I saw that I can unmount the USB devices using `gnome-disks`. I don't know why nautilus is using umount instead of udisks2 to unmount the devices.
Comment 12 Ronan Chagas 2016-10-03 16:53:03 UTC
Hi guys!

News, I think this is a Tumbleweed problem. Because if I download the Live CD of  Tumbleweed and test in a VM, then it is working perfectly. However, when I install Tumbleweed in the same VM, then it does not work anymore. Hence, it must be something related to the default configuration I think.
Comment 13 Kunigumi Yen 2016-10-05 18:45:24 UTC
I also got same problem when I upgrade to Tumbleweed 20160927 (Gnome 3.20 to 3.22).
A user umount (or eject via Nautilus) the external device it not work, unless use gnome-disks or root user.
Today up to Tumbleweed 20161003, the problem persists.
Comment 14 Ronan Chagas 2016-10-05 20:40:52 UTC
Hi Kunigumi Yen,

Thanks! I was starting to think it was some local problem here.

I reported the issue to upstream also:

https://bugzilla.gnome.org/show_bug.cgi?id=772306

Can you please comment there? As of now, I do not know if it is an openSUSE bug or a GNOME bug triggered by a set of configurations in openSUSE.
Comment 15 Ronan Chagas 2016-10-06 10:07:12 UTC
Hi,

The things got more weird :)

If I install Tumbleweed from GNOME LiveCD, then I **do not** see the problem. However, if I install Tumbleweed from the Installation DVD, then I **see** the problem (http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-DVD-x86_64-Current.iso). Hence, it must be a configuration problem. However, I was not able to find what is different.

Does anyone have any idea what changes between the installation from the GNOME LiveCD and the DVD installation?
Comment 16 Ronan Chagas 2016-10-06 12:39:43 UTC
FOUND THE PROBLEM!

In my openSUSE installation and when I install openSUSE from the installation CD, the directory /var/run **is not** a symlink to /run

Otherwise, when I installed from LiveCD, the /var/run is indeed a symlink to /run

I needed to reboot in maintenance mode, unmount /var/run, remove it, symlink to /run

After a reboot, everything started to work again. Hence, it seems to be an openSUSE installation bug.
Comment 17 Dominique Leuenberger 2016-10-06 12:47:28 UTC
Nice debug work Ronan!

Now up to finding why this would go wrong.

filesystem does, it it's pre-install script:

if not posix.stat("/var/run") then
  posix.symlink("/run","/var/run")
end

Which can only mean that when the installation happened, /var/run existed already (otherwise it would have been symlinked)

So the big question will be to find what was evil enough to create this directory
Comment 18 Dominique Leuenberger 2016-10-06 12:50:14 UTC
zypper se --file-list /var/run

lists only two packages:
* filesystem (expected, it ghost own the directory)
* ntp (it should likely also use /run - it's the only cause I can find)

One way to possible test this would be to perform an installation from DVD and explicitly unselect / taboo 'ntp' during the installation.

If this problem disappears, we're sure it's NTP. If it doesn't disappear, we can not be sure it's not ntp (it could have been including data into installation-images already)
Comment 19 Wolfgang Bauer 2016-10-06 13:23:53 UTC
For the record, I did a fresh Tumbleweed installation in VirtualBox yesterday (default KDE install, with the NET ISO), and /var/run/ was a symlink to /run/.

And ntp was/is installed, so it's maybe not the culprit (or the problem has been fixed already...)
Comment 20 Dominique Leuenberger 2016-10-06 13:30:30 UTC
(In reply to Wolfgang Bauer from comment #19)
> For the record, I did a fresh Tumbleweed installation in VirtualBox
> yesterday (default KDE install, with the NET ISO), and /var/run/ was a
> symlink to /run/.
> 
> And ntp was/is installed, so it's maybe not the culprit (or the problem has
> been fixed already...)

Or the issue only happens with the DVD - installing from the live image means also using the NET installer - as Ronan said, then the problem does not appear; only when installing from the DVD
Comment 21 Wolfgang Bauer 2016-10-06 13:42:21 UTC
(In reply to Dominique Leuenberger from comment #20)
> Or the issue only happens with the DVD - installing from the live image
> means also using the NET installer - as Ronan said, then the problem does
> not appear; only when installing from the DVD

Right, I just wanted to mention it. (And I forgot about the fact that the LiveCD is using the NET installer nowadays... Sorry for that.)

May be related to the order in which the packages are installed too I suppose, might explain a difference between a KDE and a GNOME install.
But probably not between a GNOME install using the DVD or the NET ISO...

What may be a difference though is that the NET installer downloads the current versions from the online repos, while the DVD is fixed.
So maybe it would be a good idea to retry with the latest DVD?
Comment 22 Ronan Chagas 2016-10-07 07:36:11 UTC
(In reply to Dominique Leuenberger from comment #17)
> Nice debug work Ronan!
> 
> Now up to finding why this would go wrong.
> 
> filesystem does, it it's pre-install script:
> 
> if not posix.stat("/var/run") then
>   posix.symlink("/run","/var/run")
> end
> 
> Which can only mean that when the installation happened, /var/run existed
> already (otherwise it would have been symlinked)
> 
> So the big question will be to find what was evil enough to create this
> directory

Hi Dominique,

Thanks! I installed Tumbleweed again disabling NTP at installation (using the standard DVD) and the problem continues. Any new ideas?
Comment 23 Ronan Chagas 2016-10-07 07:37:41 UTC
(In reply to Wolfgang Bauer from comment #21)
> What may be a difference though is that the NET installer downloads the
> current versions from the online repos, while the DVD is fixed.
> So maybe it would be a good idea to retry with the latest DVD?

Hi!

I am already using the latest available Tumbleweed ISO.
Comment 24 Dominique Leuenberger 2016-10-07 07:42:18 UTC
One question for my clarification: when you talk about the 'GNOME Live CD' that us the 'Tumbleweed GNOME Live CD', same snapshot number as the DVD, right?
Comment 25 Ronan Chagas 2016-10-07 08:18:24 UTC
(In reply to Dominique Leuenberger from comment #24)
> One question for my clarification: when you talk about the 'GNOME Live CD'
> that us the 'Tumbleweed GNOME Live CD', same snapshot number as the DVD,
> right?

Exactly!
Comment 26 Andrei Borzenkov 2016-10-07 08:45:57 UTC
(In reply to Dominique Leuenberger from comment #18)
> * ntp (it should likely also use /run - it's the only cause I can find)
> 

ntp matches due to /var/lib/ntp/var/run so it cannot trigger /var/run creation. The worst case is if some script does "mkdir -p /var/run/foo" during installation. Not sure if there is feasible method to check it. Is it possible single-step installation? Then we could check after every package when /var/run appears.
Comment 27 Ronan Chagas 2016-10-07 09:45:35 UTC
I started the installation and begin to continuously type `ls` in the console. I figured out that the /var/run directory is created during the process of deploying GNOME image. Does it make any sense?
Comment 28 Dominique Leuenberger 2016-10-07 10:26:18 UTC
(In reply to Ronan Chagas from comment #27)
> I started the installation and begin to continuously type `ls` in the
> console. I figured out that the /var/run directory is created during the
> process of deploying GNOME image. Does it make any sense?

yes. this is pretty much where I started looking in already and what I expected...

from what I found in the images there is a stale zypp.pid in there for some reason.

https://build.opensuse.org/package/rdiff/openSUSE:Factory:Live/openSUSE-images?linkrev=base&rev=27

is an attempt to get this fixed already (I reverted the first - was not happy with the partial clenaup only) - the next snapshot will show it to be true/false
Comment 29 Emanuel Castelo 2016-10-07 21:10:21 UTC
System:    Host: linux-s4s1 Kernel: 4.7.5-1-default x86_64 (64 bit gcc: 6.2.1)
           Desktop: Cinnamon 3.0.7  dm: sddm,sddm Distro: openSUSE Tumbleweed

found file with possible reference to symlink, not sure if it pertains, 

/usr/lib/dracut/modules.d/30convertfs/convertfs.sh
-rwxr-xr-x 1 root root 6035 Nov 25  2015 convertfs.sh
Comment 30 Emanuel Castelo 2016-10-07 21:17:20 UTC
(In reply to Emanuel Castelo from comment #29)
> System:    Host: linux-s4s1 Kernel: 4.7.5-1-default x86_64 (64 bit gcc:
> 6.2.1)
>            Desktop: Cinnamon 3.0.7  dm: sddm,sddm Distro: openSUSE Tumbleweed
> 
> found file with possible reference to symlink, not sure if it pertains, 
> 
> /usr/lib/dracut/modules.d/30convertfs/convertfs.sh
> -rwxr-xr-x 1 root root 6035 Nov 25  2015 convertfs.sh

https://gist.github.com/anonymous/64e1fb32751bb9611522982148d348cd file content as found and snippet:


if [ ! -L $ROOT/var/run -a -e $ROOT/var/run ]; then
    echo "Converting /var/run to symlink"
    mv -f $ROOT/var/run $ROOT/var/run.runmove~
    ln -sfn ../run $ROOT/var/run
fi
Comment 31 Dominique Leuenberger 2016-10-12 15:41:03 UTC
Ronan,

Can you please test with the latest DVD (20161010) if this problem still exists or if my fix worked?
Comment 32 Ronan Chagas 2016-10-13 15:26:08 UTC
(In reply to Dominique Leuenberger from comment #31)
> Ronan,
> 
> Can you please test with the latest DVD (20161010) if this problem still
> exists or if my fix worked?

Sure! I'm downloading openSUSE-Tumbleweed-DVD-x86_64-Snapshot20161010-Media.iso right now to test.
Comment 33 Ronan Chagas 2016-10-13 16:44:06 UTC
Hi Dominique,

I can confirm that /var/run is now a symlink to /run if I use the lastest ISO to install Tumbleweed. Hence, unmounting USB devices as an user is working perfectly. Thus, we can consider this bug closed.

Just one more thing, by the way, can you provide a recipe so that users who installed Tumbleweed before this snapshot can fix their systems without reinstall?

What I did was:

1) Reboot in maintenance mode (INIT 1);
2) Unmount /var/run (I guess it is bind mounted to /run);
3) rm -rf /var/run
4) cd /var
5) ln -sf ./run ../run

Are those steps fine?
Comment 34 Atri Bhattacharya 2016-10-14 22:47:19 UTC
(In reply to Ronan Chagas from comment #33)
> 
> 1) Reboot in maintenance mode (INIT 1);
> 2) Unmount /var/run (I guess it is bind mounted to /run);
> 3) rm -rf /var/run
> 4) cd /var
> 5) ln -sf ./run ../run
> 

Is something like this really necessary? Shouldn't
https://git.gnome.org/browse/gvfs/commit/?id=be0c464
fix things (at least the issue with nautilus being unable to unmount) automatically?
Comment 35 Ronan Chagas 2016-10-14 23:02:02 UTC
(In reply to Atri Bhattacharya from comment #34)
> (In reply to Ronan Chagas from comment #33)
> > 
> > 1) Reboot in maintenance mode (INIT 1);
> > 2) Unmount /var/run (I guess it is bind mounted to /run);
> > 3) rm -rf /var/run
> > 4) cd /var
> > 5) ln -sf ./run ../run
> > 
> 
> Is something like this really necessary? Shouldn't
> https://git.gnome.org/browse/gvfs/commit/?id=be0c464
> fix things (at least the issue with nautilus being unable to unmount)
> automatically?

Yes, this should fix this problem. However, AFAIK, /var/run must be a symlink to /run nowadays. Hence, I think other bugs can occur if this is not fixed.
Comment 36 Ronan Chagas 2017-01-02 23:07:39 UTC
Guys, the new installations of Tumbleweed does not have this problem. We can close it.