4:32 p.m.
Hello,
Fedora 20 KDE Thinkpad T420i laptop has started mounting Transcend StoreJet
25M3 as read-only. I tried remounting with rw but it is still mounted as ro.
The system is fully updated. I have recently scrub-ed the external drive to
prepare for backup.
[donnie@fedora ~]$ mount | grep /dev/sdb1
/dev/sdb1 on /run/media/donnie/storejet25m3 type ext4
(ro,nosuid,nodev,relatime,seclabel,data=ordered,uhelper=udisks2)
[donnie@fedora ~]$ ls -l /run/media/donnie/storejet25m3
total 16
drwx------. 2 root root 16384 Aug 31 12:55 lost+found
--
Sudhir Khanger,
http://sudhirkhanger.com
http://github.com/donniezazen
6:34 p.m.
On Monday, September 01, 2014 07:25:06 AM Ed Greshko wrote:
On 09/01/14 07:19, Joe Z eff wrote:
> On 08/31/2014 04:05 PM, Ed Greshko wrote:
>> On 09/01/14 06:59, Ed Greshko wrote:
>>> The selinux "warning" is fixed by "restorecon -R /mnt"
>>
>> I meant "restorecon -R /mnt/test" Missed your different mount
point.
>> :-(>
> In this case it didn't matter because you used -R, meaning
"recursive."
I prefer to be precise.
It didn't do any good. I can't write to the disk without superuser previleges.
Even if that would have made the disk writable I wouldn't want to use two
commands each time I hook up a usb disk. And it was working before anyways.
There were some broken updates this afternoon.
[donnie@fedora mnt]$ sudo yum history info 161
Loaded plugins: changelog, fastestmirror, langpacks, local, show-leaves
Transaction ID : 161
Begin time : Sun Aug 31 22:55:38 2014
Begin rpmdb : 2136:a8f8e8b619928f0c975985d3b04a0602901cdb99
End time : 23:04:51 2014 (9 minutes)
End rpmdb : 2143:741ea78c78676ca5bf24a55edd8e4193e940de47
User : Sudhir Khanger <donnie>
Return-Code : Success
Command Line : upgrade --skip-broken
Transaction performed with:
Installed rpm-4.11.2-2.fc20.x86_64 @_local
Installed yum-3.4.3-152.fc20.noarch @_local
Installed yum-metadata-parser-1.1.4-9.fc20.x86_64 @koji-
override-0/$releasever
Installed yum-plugin-fastestmirror-1.1.31-23.fc20.noarch @updates
Packages Altered:
Updated akregator-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated akregator-libs-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
_local
| 2.9 kB 00:00:00
fedora-HandBrake
| 2.9 kB 00:00:00
fedora-flash-plugin
| 2.9 kB 00:00:00
fedora-skype
| 2.9 kB 00:00:00
google-chrome
| 951 B 00:00:00
google-talkplugin
| 951 B 00:00:00
google-webdesigner
| 951 B 00:00:00
home_moritzmolch_gencfsm
| 1.6 kB 00:00:00
kde
| 2.9 kB 00:00:00
kde-testing
| 2.9 kB 00:00:00
rpmfusion-free-updates
| 3.3 kB 00:00:00
rpmfusion-nonfree-updates
| 3.3 kB 00:00:00
updates/20/x86_64/metalink
| 5.4 kB 00:00:00
virtualbox
| 951 B 00:00:00
_local/primary_db
| 2.2 MB 00:00:00
Loading mirror speeds from cached hostfile
* fedora: mirror.dhakacom.com
* kde: kdeforge.unl.edu
* kde-testing: kdeforge.unl.edu
* rpmfusion-free: mirror.cse.iitk.ac.in
* rpmfusion-free-updates: mirror.cse.iitk.ac.in
* rpmfusion-nonfree: mirror.smartmedia.net.id
* rpmfusion-nonfree-updates: mirror.smartmedia.net.id
* tlp: repo.warpnine.de
* tlp-updates: repo.warpnine.de
* updates: mirror.dhakacom.com
Updated baloo-4.13.3-1.fc20.x86_64
@?_local
Obsoleted baloo-4.13.3-1.fc20.x86_64
@?_local
Update baloo-4.13.3-3.fc20.x86_64
@updates
Obsoleting baloo-akonadi-4.13.3-3.fc20.x86_64
@updates
Updated baloo-file-4.13.3-1.fc20.x86_64
@?_local
Update 4.13.3-3.fc20.x86_64
@updates
Updated baloo-libs-4.13.3-1.fc20.x86_64
@?_local
Update 4.13.3-3.fc20.x86_64
@updates
Updated blogilo-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kaddressbook-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kaddressbook-libs-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kalarm-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kdepim-7:4.13.3-11.fc20.x86_64
@kde-testing
Update 7:4.13.3-12.fc20.x86_64
@updates
Updated kdepim-common-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kdepim-libs-7:4.13.3-11.fc20.x86_64
@kde-testing
Update 7:4.13.3-12.fc20.x86_64
@updates
Erase kernel-3.15.6-200.fc20.x86_64
@_local
Install kernel-3.15.10-201.fc20.x86_64
@updates
Erase kernel-devel-3.15.6-200.fc20.x86_64
@_local
Install kernel-devel-3.15.10-201.fc20.x86_64
@updates
Updated kernel-headers-3.15.10-200.fc20.x86_64
@updates
Update 3.15.10-201.fc20.x86_64
@updates
Erase kernel-modules-extra-3.15.6-200.fc20.x86_64
@_local
Install kernel-modules-extra-3.15.10-201.fc20.x86_64
@updates
Updated kjots-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kleopatra-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kleopatra-libs-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kmail-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kmail-libs-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Erase kmod-acpi_call-3.15.6-200.fc20.x86_64-1.1.0-2.fc20.x86_64 ?
Erase kmod-tp_smapi-3.15.6-200.fc20.x86_64-0.41-4.fc20.x86_64 ?
Updated knode-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated knode-libs-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated knotes-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated knotes-libs-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kontact-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated kontact-libs-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated korganizer-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated korganizer-libs-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Updated ktimetracker-4.13.3-11.fc20.x86_64
@kde-testing
Update 4.13.3-12.fc20.x86_64
@updates
Dep-Install libgpod-0.8.3-1.fc20.i686
@fedora
Dep-Install libgpod-sharp-0.8.3-1.fc20.i686
@fedora
Dep-Install libimobiledevice-1.1.5-3.fc20.i686
@fedora
Dep-Install libplist-1.10-2.fc20.i686
@fedora
Updated openvpn-2.3.2-4.fc20.x86_64
@koji-override-0/$releasever
Update 2.3.2-6.fc20.x86_64
@updates
Updated selinux-policy-3.12.1-181.fc20.noarch
@updates
Update 3.12.1-182.fc20.noarch
@updates
Updated selinux-policy-targeted-3.12.1-181.fc20.noarch
@updates
Update 3.12.1-182.fc20.noarch
@updates
Dep-Install sg3_utils-libs-1.37-2.fc20.i686
@fedora
Dep-Install usbmuxd-1.0.8-10.fc20.i686
@fedora
Packages Skipped:
Newer ifuse-1.1.3-3.fc20.x86_64
Newer libgpod-0.8.3-2.fc20.x86_64
Newer libgpod-sharp-0.8.3-2.fc20.x86_64
Newer libimobiledevice-1.1.6-2.fc20.x86_64
Newer libplist-1.11-2.fc20.x86_64
Not installed libusbmuxd-1.0.9-2.fc20.x86_64
Newer usbmuxd-1.0.9-0.4.c24463e.fc20.x86_64
Scriptlet output:
1 dkms: removing: vboxhost 4.3.14 (3.15.6-200.fc20.x86_64) (x86_64)
2
3 -------- Uninstall Beginning --------
4 Module: vboxhost
5 Version: 4.3.14
6 Kernel: 3.15.6-200.fc20.x86_64 (x86_64)
7 -------------------------------------
8
9 Status: Before uninstall, this module version was ACTIVE on this kernel.
10 Removing any linked weak-modules
11
12 vboxdrv.ko:
13 - Uninstallation
14 - Deleting from: /lib/modules/3.15.6-200.fc20.x86_64/extra/
15 - Original module
16 - No original module was found for this module on this kernel.
17 - Use the dkms install command to reinstall any previous module
version.
18
19
20 vboxnetflt.ko:
21 - Uninstallation
22 - Deleting from: /lib/modules/3.15.6-200.fc20.x86_64/extra/
23 - Original module
24 - No original module was found for this module on this kernel.
25 - Use the dkms install command to reinstall any previous module
version.
26
27
28 vboxnetadp.ko:
29 - Uninstallation
30 - Deleting from: /lib/modules/3.15.6-200.fc20.x86_64/extra/
31 - Original module
32 - No original module was found for this module on this kernel.
33 - Use the dkms install command to reinstall any previous module
version.
34
35
36 vboxpci.ko:
37 - Uninstallation
38 - Deleting from: /lib/modules/3.15.6-200.fc20.x86_64/extra/
39 - Original module
40 - No original module was found for this module on this kernel.
41 - Use the dkms install command to reinstall any previous module
version.
42
43 depmod...
44
45 DKMS: uninstall completed.
46 warning: file /lib/modules/3.15.6-200.fc20.x86_64/updates: remove failed:
No such file or directory
history info
--
Sudhir Khanger,
http://sudhirkhanger.com
http://github.com/donniezazen
2:32 a.m.
On 09/03/14 13:50, Sudhir Khanger wrote:
On Wednesday, September 03, 2014 06:25:05 AM Ed Greshko wrote:
> The GID/UID scheme has been around since the dawn of Unix. Anyone cannot
> chown, they need to be root. It isn't, and never was intended, to be a
> method of securing access to external drives. If you need to secure access
> to data on an external drive then you need to use encrypted partitions.
It's like Linus's printer rant. You setup laptops for family member and they
regularly require root password for mundane tasks like hooking up a printer or
an external hard drive, etc.
That rant is out of date....
You don't need root to do those tasks. All that needs doing is placing the
"family member" in the wheel group. This is done at install time by a
"checkbox". Then all the user needs do is use their own password when prompted
for "authentication" by the system.
--
If you can't laugh at yourself, others will gladly oblige.
12:50 a.m.
On Wednesday, September 03, 2014 06:25:05 AM Ed Greshko wrote:
The GID/UID scheme has been around since the dawn of Unix. Anyone
cannot
chown, they need to be root. It isn't, and never was intended, to be a
method of securing access to external drives. If you need to secure access
to data on an external drive then you need to use encrypted partitions.
It's like Linus's printer rant. You setup laptops for family member and they
regularly require root password for mundane tasks like hooking up a printer or
an external hard drive, etc.
--
Sudhir Khanger,
http://sudhirkhanger.com
http://github.com/donniezazen
5:25 p.m.
On 09/03/14 03:46, Sudhir Khanger wrote:
This is a very weird scheme of things. We allow a system with generic
set of
UID/GID but block on some. If all you need to access a hard drive's data is to
set correct UID/GID then why bother about it all. And anyone can chown the
disk and have any sort of access they want. It should be automatically ported
to the current user for sake of convenience at least for folks who use
graphical file managers.
The GID/UID scheme has been around since the dawn of Unix. Anyone cannot chown, they need
to be root.
It isn't, and never was intended, to be a method of securing access to external
drives. If you need to secure access to data on an external drive then you need to use
encrypted partitions.
Anyway, your problem has been resolved.
--
If you can't laugh at yourself, others will gladly oblige.
2:46 p.m.
On Tuesday, September 02, 2014 05:07:36 AM Ed Greshko wrote:
And, as others have already pointed out, it is the numerical UID/GID
being
the same across all systems which makes it work. I mentioned all of this
earlier on in this thread....
This is a very weird scheme of things. We allow a system with generic set of
UID/GID but block on some. If all you need to access a hard drive's data is to
set correct UID/GID then why bother about it all. And anyone can chown the
disk and have any sort of access they want. It should be automatically ported
to the current user for sake of convenience at least for folks who use
graphical file managers.
--
Sudhir Khanger,
http://sudhirkhanger.com
http://github.com/donniezazen
3:07 a.m.
On Mon, Sep 1, 2014 at 1:11 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
Yes... UNTIL I "fix" it with using the chown command as
I've now said multiple times.
I will have to try other distribution. I don't remember doing anything
like that when mounting through graphical means. I was talking to some
folks at #archlinux and they also said when mounting through graphical
means no chowning is required even for ext4 filesystem. I will have to
try that myself.
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
3:26 a.m.
On 09/01/14 16:25, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 1:50 PM, Ed Greshko
<ed.greshko(a)greshko.com> wrote:
> Once you chown on the file system you never have to do it again. I think you're
making a mountain out of a molehill.
The only way to tell if this is a mountain or a molehill is to try
some other distribution.
Thank you for keep trying to help me.
Have fun....
--
If you can't laugh at yourself, others will gladly oblige.
2:41 a.m.
On 09/01/14 15:30, Sudhir Khanger wrote:
On your system when mounting ext4 usb-storage through a graphical
file
manager like Dolphin or Nautilus is it mounted under root:root user?
Yes... UNTIL I "fix" it with using the chown command as I've now said
multiple times.
--
If you can't laugh at yourself, others will gladly oblige.
3:25 a.m.
On Mon, Sep 1, 2014 at 1:50 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
Once you chown on the file system you never have to do it again. I
think you're making a mountain out of a molehill.
The only way to tell if this is a mountain or a molehill is to try
some other distribution.
Thank you for keep trying to help me.
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
3:13 a.m.
On 09/01/14 16:07, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 1:11 PM, Ed Greshko
<ed.greshko(a)greshko.com> wrote:
> Yes... UNTIL I "fix" it with using the chown command as I've now said
multiple times.
I will have to try other distribution. I don't remember doing anything
like that when mounting through graphical means. I was talking to some
folks at #archlinux and they also said when mounting through graphical
means no chowning is required even for ext4 filesystem. I will have to
try that myself.
If you want to not worry about user and group names then simply change to use a different
filesystem type!!!!
mkfs.ntfs /dev/sdg1 or whatever partition is to be hold the file system.
--
If you can't laugh at yourself, others will gladly oblige.
3:20 a.m.
On 09/01/14 16:13, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 1:37 PM, Sudhir Khanger
<sudhir(a)sudhirkhanger.com> wrote:
> On Mon, Sep 1, 2014 at 1:11 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
>> Yes... UNTIL I "fix" it with using the chown command as I've now
said multiple times.
>
> I will have to try other distribution. I don't remember doing anything
> like that when mounting through graphical means. I was talking to some
> folks at #archlinux and they also said when mounting through graphical
> means no chowning is required even for ext4 filesystem. I will have to
> try that myself.
Also I remember that an ext4 disk would mount as $USER:users on Arch
Linux or $USER: $USER on something like Ubuntu. You didn't have to
chown the folder you mount to.
Once you chown on the file system you never have to do it again. I think you're
making a mountain out of a molehill.
--
If you can't laugh at yourself, others will gladly oblige.
3:15 a.m.
On Mon, Sep 1, 2014 at 1:43 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
If you want to not worry about user and group names then simply
change to use a different filesystem type!!!!
mkfs.ntfs /dev/sdg1 or whatever partition is to be hold the file system.
If you regularly move files across devices to and from ntfs drive then
all you permissions get messed up.
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
3:13 a.m.
On Mon, Sep 1, 2014 at 1:37 PM, Sudhir Khanger <sudhir(a)sudhirkhanger.com> wrote:
On Mon, Sep 1, 2014 at 1:11 PM, Ed Greshko
<ed.greshko(a)greshko.com> wrote:
> Yes... UNTIL I "fix" it with using the chown command as I've now said
multiple times.
I will have to try other distribution. I don't remember doing anything
like that when mounting through graphical means. I was talking to some
folks at #archlinux and they also said when mounting through graphical
means no chowning is required even for ext4 filesystem. I will have to
try that myself.
Also I remember that an ext4 disk would mount as $USER:users on Arch
Linux or $USER: $USER on something like Ubuntu. You didn't have to
chown the folder you mount to.
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
2:40 a.m.
On 09/01/14 15:30, Sudhir Khanger wrote:
Yes, the disk is being mounted as RW but not as a regular user.
On your system when mounting ext4 usb-storage through a graphical file
manager like Dolphin or Nautilus is it mounted under root:root user?
The disk gets mounted with permissions and ownership as stored in the file system when
using ext4. That is the way the filesystem works.
The command that I gave you "sudo chmod 1777 /run/media/donnie/storejet" will
make the filesystem be the same as /tmp.
[root@meimei ~]# ll -d /tmp
drwxrwxrwt. 16 root root 440 Sep 1 15:12 /tmp
This allows anyone to write to the file system and since the sticky bit is set (t) only
allows the owner of the file to delete it.
Now, if you want the file system to be mounted as a given user you can use the chown
command.
As an example.....
[root@meimei ~]# grep maria /etc/passwd
maria:x:1003:1003:Maria Yang:/home/maria:/bin/bash
[root@meimei ~]# ll -d /run/media/egreshko/ext
drwxr-xr-x. 3 maria maria 4096 Sep 1 06:29 /run/media/egreshko/ext
Now, every time that partition is mounted it will be mounted as owned by maria and group
maria. The downside with that is if you have system where the UID/GID aren't 1003.
--
If you can't laugh at yourself, others will gladly oblige.
2:30 a.m.
On Mon, Sep 1, 2014 at 12:41 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 09/01/14 15:08, Sudhir Khanger wrote:
> On Mon, Sep 1, 2014 at 12:33 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
>> What do you mean?
>>
>> If you do
>>
>> sudo touch /run/media/donnie/storejet/x
>>
>> what do you get?
> That works fine that will write file x with root:root
Yes.... Which *PROVES* it is mounted RW....
>
> I was checking dmesg. There are some interesting errors and remounting
> filesystem read-only
>
Now, do this....
sudo chmod 1777 /run/media/donnie/storejet
And then, without sudo.....
touch y
Don't use "touch x" as that is owned by root.
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Yes, the disk is being mounted as RW but not as a regular user.
On your system when mounting ext4 usb-storage through a graphical file
manager like Dolphin or Nautilus is it mounted under root:root user?
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
2:11 a.m.
On 09/01/14 15:08, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 12:33 PM, Ed Greshko
<ed.greshko(a)greshko.com> wrote:
> What do you mean?
>
> If you do
>
> sudo touch /run/media/donnie/storejet/x
>
> what do you get?
That works fine that will write file x with root:root
Yes.... Which *PROVES* it is mounted RW....
I was checking dmesg. There are some interesting errors and remounting
filesystem read-only
Now, do this....
sudo chmod 1777 /run/media/donnie/storejet
And then, without sudo.....
touch y
Don't use "touch x" as that is owned by root.
--
If you can't laugh at yourself, others will gladly oblige.
2:08 a.m.
On Mon, Sep 1, 2014 at 12:33 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
What do you mean?
If you do
sudo touch /run/media/donnie/storejet/x
what do you get?
That works fine that will write file x with root:root
I was checking dmesg. There are some interesting errors and remounting
filesystem read-only
[donnie@fedora ~]$ dmesg | grep sdc1
[ 3814.291553] sdc: sdc1
[ 3834.818254] EXT4-fs (sdc1): recovery complete
[ 3834.868368] EXT4-fs (sdc1): mounted filesystem with ordered data
mode. Opts: (null)
[ 3834.868396] SELinux: initialized (dev sdc1, type ext4), uses xattr
[ 3946.389358] Aborting journal on device sdc1-8.
[ 3946.389380] JBD2: Error -5 detected when updating journal
superblock for sdc1-8.
[ 3946.411350] EXT4-fs error (device sdc1): ext4_put_super:792:
Couldn't clean up the journal
[ 3946.411355] EXT4-fs (sdc1): Remounting filesystem read-only
[ 4358.549028] sdc: sdc1
[ 4363.302847] EXT4-fs (sdc1): recovery complete
[ 4363.341497] EXT4-fs (sdc1): mounted filesystem with ordered data
mode. Opts: (null)
[ 4363.341513] SELinux: initialized (dev sdc1, type ext4), uses xattr
[donnie@fedora ~]$ dmesg | grep sdc
[ 3814.230640] sd 11:0:0:0: [sdc] 1953525168 512-byte logical blocks:
(1.00 TB/931 GiB)
[ 3814.232519] sd 11:0:0:0: [sdc] Write Protect is off
[ 3814.232529] sd 11:0:0:0: [sdc] Mode Sense: 43 00 00 00
[ 3814.236145] sd 11:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 3814.291553] sdc: sdc1
[ 3814.295212] sd 11:0:0:0: [sdc] Attached SCSI disk
[ 3834.818254] EXT4-fs (sdc1): recovery complete
[ 3834.868368] EXT4-fs (sdc1): mounted filesystem with ordered data
mode. Opts: (null)
[ 3834.868396] SELinux: initialized (dev sdc1, type ext4), uses xattr
[ 3946.389358] Aborting journal on device sdc1-8.
[ 3946.389380] JBD2: Error -5 detected when updating journal
superblock for sdc1-8.
[ 3946.392034] sd 11:0:0:0: [sdc] Synchronizing SCSI cache
[ 3946.392089] sd 11:0:0:0: [sdc]
[ 3946.411350] EXT4-fs error (device sdc1): ext4_put_super:792:
Couldn't clean up the journal
[ 3946.411355] EXT4-fs (sdc1): Remounting filesystem read-only
[ 4358.479465] sd 13:0:0:0: [sdc] 1953525168 512-byte logical blocks:
(1.00 TB/931 GiB)
[ 4358.480975] sd 13:0:0:0: [sdc] Write Protect is off
[ 4358.480985] sd 13:0:0:0: [sdc] Mode Sense: 43 00 00 00
[ 4358.483225] sd 13:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 4358.549028] sdc: sdc1
[ 4358.553304] sd 13:0:0:0: [sdc] Attached SCSI disk
[ 4363.302847] EXT4-fs (sdc1): recovery complete
[ 4363.341497] EXT4-fs (sdc1): mounted filesystem with ordered data
mode. Opts: (null)
[ 4363.341513] SELinux: initialized (dev sdc1, type ext4), uses xattr
On your system when you mount an ext4 usb storage is it mounted as read-only?
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
2:03 a.m.
On 09/01/14 14:55, Sudhir Khanger wrote:
I ran
sudo scrub -fp dod /dev/sdb
It show it is mounted as RW but it is actually RO.
[donnie@fedora ~]$ mount | grep /dev/sdc
/dev/sdc1 on /run/media/donnie/storejet type ext4
(rw,nosuid,nodev,relatime,seclabel,data=ordered,uhelper=udisks2)
[donnie@fedora ~]$ ls -l /run/media/donnie/storejet
total 16
drwx------. 2 root root 16384 Sep 1 12:15 lost+found
What do you mean?
If you do
sudo touch /run/media/donnie/storejet/x
what do you get?
--
If you can't laugh at yourself, others will gladly oblige.
1:55 a.m.
On Mon, Sep 1, 2014 at 11:44 AM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 09/01/14 14:04, Sudhir Khanger wrote:
> On Mon, Sep 1, 2014 at 8:44 AM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
>> Yep, so many ways to solve the "problem". Just depends on what the
goal of end user happens to be. At least the most pressing issue for the OP has been
resolved as the partition no longer mounts RO.
> I find it odd that the ext4 disk is being mounted as read-only. From
> what I remember I have always used ex4 drive and I never had to this
> problem. All my external drives are always mounted as read-write. Are
> you sure if this is not a bug?
>
It is *no longer* being mounted as RO.
The fsck fixed that when it recovered the journal.
Exactly what "scrub" command did you use? I can test to see if it results in
damage to the journal and see if the issue is reproducible.
In your message of "Mon, 01 Sep 2014 04:23:14 +0530" you showed....
mount | grep /dev/sdb
/dev/sdb1 on /mnt/test type ext4 (rw,relatime,seclabel,data=ordered)
So, you demonstrated that it is now being mounted RW.
So, all you need to do is "change" permissions on the mounted file system to
meet your needs. Then you won't have to change to root, or use sudo.
Look back on suggestions being offered by myself and others.
--
If you can't laugh at yourself, others will gladly oblige.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
I ran
sudo scrub -fp dod /dev/sdb
It show it is mounted as RW but it is actually RO.
[donnie@fedora ~]$ mount | grep /dev/sdc
/dev/sdc1 on /run/media/donnie/storejet type ext4
(rw,nosuid,nodev,relatime,seclabel,data=ordered,uhelper=udisks2)
[donnie@fedora ~]$ ls -l /run/media/donnie/storejet
total 16
drwx------. 2 root root 16384 Sep 1 12:15 lost+found
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
1:14 a.m.
On 09/01/14 14:04, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 8:44 AM, Ed Greshko
<ed.greshko(a)greshko.com> wrote:
> Yep, so many ways to solve the "problem". Just depends on what the goal of
end user happens to be. At least the most pressing issue for the OP has been resolved as
the partition no longer mounts RO.
I find it odd that the ext4 disk is being mounted as read-only. From
what I remember I have always used ex4 drive and I never had to this
problem. All my external drives are always mounted as read-write. Are
you sure if this is not a bug?
It is *no longer* being mounted as RO.
The fsck fixed that when it recovered the journal.
Exactly what "scrub" command did you use? I can test to see if it results in
damage to the journal and see if the issue is reproducible.
In your message of "Mon, 01 Sep 2014 04:23:14 +0530" you showed....
mount | grep /dev/sdb
/dev/sdb1 on /mnt/test type ext4 (rw,relatime,seclabel,data=ordered)
So, you demonstrated that it is now being mounted RW.
So, all you need to do is "change" permissions on the mounted file system to
meet your needs. Then you won't have to change to root, or use sudo.
Look back on suggestions being offered by myself and others.
--
If you can't laugh at yourself, others will gladly oblige.
1:04 a.m.
On Mon, Sep 1, 2014 at 8:44 AM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
Yep, so many ways to solve the "problem". Just depends on
what the goal of end user happens to be. At least the most pressing issue for the OP has
been resolved as the partition no longer mounts RO.
I find it odd that the ext4 disk is being mounted as read-only. From
what I remember I have always used ex4 drive and I never had to this
problem. All my external drives are always mounted as read-write. Are
you sure if this is not a bug?
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
10:14 p.m.
On 09/01/14 11:07, Tim wrote:
On Mon, 2014-09-01 at 07:52 +0800, Ed Greshko wrote:
> If you want to use a usb disk such that anyone that plugs it in can
> write to it then you need to use ntfs or another of the wonderful MS
> filesystems types.
Or you can make some sub-directories, owned by particular users. That's
what I've done with external drives. And it stops the root directory of
the drive been filled up with thousands of personal files.
Yep, so many ways to solve the "problem". Just depends on what the goal
of end user happens to be. At least the most pressing issue for the OP has been resolved
as the partition no longer mounts RO.
--
If you can't laugh at yourself, others will gladly oblige.
10:07 p.m.
On Mon, 2014-09-01 at 07:52 +0800, Ed Greshko wrote:
If you want to use a usb disk such that anyone that plugs it in can
write to it then you need to use ntfs or another of the wonderful MS
filesystems types.
Or you can make some sub-directories, owned by particular users. That's
what I've done with external drives. And it stops the root directory of
the drive been filled up with thousands of personal files.
--
tim@localhost ~]$ uname -rsvp
Linux 3.15.10-201.fc20.i686 #1 SMP Wed Aug 27 21:33:30 UTC 2014 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
4:07 p.m.
On 09/01/14 22:04, Sudhir Khanger wrote:
I haven't had time to look into it myself but more I read about
ext4
your tryst explaining me earlier becomes more clear that permissions
persist with the filesystem. Now that I think more about it one
possibility is that I use same username across systems which might
have made it possible to mount with RW without superuser privileges.
Please be careful to use the correct terminology. Failure to do so in the future may
cause people to misunderstand you.
The drive is being mounted RW. It has nothing to do with "superuser
privileges". The RO vs RW was fixed when the journal was recovered as a result of
"fsck" being run.
The drive is RW. The user was unable to write to it due to "permission"
issues.
You also need to read up on that and ownership. man chmod and man chown may be helpful in
your understanding.
I also did following to the ext4 drive.
chown $USER:$USER /run/media/$USER/storjet
That is all I had to do and the drive seems to not give heartache
anymore. Home user has all the privileges I need.
And, as others have already pointed out, it is the numerical UID/GID being the same across
all systems which makes it work. I mentioned all of this earlier on in this thread....
Now time to run that attic-backup.
Thanks again Ed.
Welcome and enjoy....
--
If you can't laugh at yourself, others will gladly oblige.
2:41 p.m.
On 09/01/2014 07:04 AM, Sudhir Khanger wrote:
I haven't had time to look into it myself but more I read about
ext4
your tryst explaining me earlier becomes more clear that permissions
persist with the filesystem. Now that I think more about it one
possibility is that I use same username across systems which might
have made it possible to mount with RW without superuser privileges.
My understanding is that the numerical UID and GID are what matters; the
names are just there for convenience.
10:20 a.m.
Allegedly, on or about 01 September 2014, Sudhir Khanger sent:
one possibility is that I use same username across systems which
might
have made it possible to mount with RW without superuser privileges.
Yes, but... It's not so much the user name that's important, but the
*numerical* user and group ID need to be the same (yes, there are some
systems that can remap names, but it's easier not to have to bother).
On my very old Fedora system, my username of "tim" is user number 500,
on the current version it's user number 1000. Files are stored against
the user *number*, which gets mapped against a local user name when you
list them to see who owns them.
I could be user "tim" on computer, and user "me" on another, but so
long
as they were both user number 1000, file ownership would remain mine.
Conversely, if you have two different users on different computers, but
using the same user numbers, they get access to each others files.
That's a problem that you don't want.
Have a look at the "-n" option with the "ls" command, on various
files,
to see this in practice. e.g. ls -n /home
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
ZNQR LBH YBBX
9:04 a.m.
On Mon, Sep 1, 2014 at 7:01 PM, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 09/01/14 16:25, Sudhir Khanger wrote:
> The only way to tell if this is a mountain or a molehill is to try
> some other distribution.
I guess you'll find no joy in Ubuntu..... Installed a test system and plugged in my
drive and allowed it to be automounted....
egreshko@ubuntu:~$ mount | grep sdb1
/dev/sdb1 on /media/egreshko/ext type ext4 (rw,nosuid,nodev,uhelper=udisks2)
egreshko@ubuntu:~$ df -T /dev/sdb1
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sdb1 ext4 115246568 61044 109308228 1% /media/egreshko/ext
egreshko@ubuntu:~$ ll -d /media/egreshko/ext
drwxr-xr-x. 3 1029 65539 4096 9月 1 16:34 /media/egreshko/ext/
egreshko@ubuntu:~$ touch /media/egreshko/ext/x
touch: cannot touch ‘/media/egreshko/ext/x’: Permission denied
Which is exactly what I would expect since my UID/GID on my Fedora systems is 1029/65539
and on the new Ubuntu system....
egreshko:x:1000:1000:Ed Greshko,,,:/home/egreshko:/bin/bash
I haven't had time to look into it myself but more I read about ext4
your tryst explaining me earlier becomes more clear that permissions
persist with the filesystem. Now that I think more about it one
possibility is that I use same username across systems which might
have made it possible to mount with RW without superuser privileges.
I also did following to the ext4 drive.
chown $USER:$USER /run/media/$USER/storjet
That is all I had to do and the drive seems to not give heartache
anymore. Home user has all the privileges I need.
Now time to run that attic-backup.
Thanks again Ed.
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
8:31 a.m.
On 09/01/14 16:25, Sudhir Khanger wrote:
The only way to tell if this is a mountain or a molehill is to try
some other distribution.
I guess you'll find no joy in Ubuntu..... Installed a test system and plugged in my
drive and allowed it to be automounted....
egreshko@ubuntu:~$ mount | grep sdb1
/dev/sdb1 on /media/egreshko/ext type ext4 (rw,nosuid,nodev,uhelper=udisks2)
egreshko@ubuntu:~$ df -T /dev/sdb1
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sdb1 ext4 115246568 61044 109308228 1% /media/egreshko/ext
egreshko@ubuntu:~$ ll -d /media/egreshko/ext
drwxr-xr-x. 3 1029 65539 4096 9月 1 16:34 /media/egreshko/ext/
egreshko@ubuntu:~$ touch /media/egreshko/ext/x
touch: cannot touch ‘/media/egreshko/ext/x’: Permission denied
Which is exactly what I would expect since my UID/GID on my Fedora systems is 1029/65539
and on the new Ubuntu system....
egreshko:x:1000:1000:Ed Greshko,,,:/home/egreshko:/bin/bash
--
If you can't laugh at yourself, others will gladly oblige.
5:40 p.m.
On 09/01/14 06:33, Sudhir Khanger wrote:
On Monday, September 01, 2014 06:26:56 AM Ed Greshko wrote:
> What do you mean by "scrubbed"?
http://manpages.ubuntu.com/manpages/saucy/man1/scrub.1.html
> Have you tried un-mounting and running fsck on the partition?
Disk is pretty new and it was in working condition last time I tried it.
sudo fsck /dev/sdb1
fsck from util-linux 2.24.2
e2fsck 1.42.8 (20-Jun-2013)
storejet25m3: recovering journal
storejet25m3: clean, 11/61054976 files, 3883091/244190208 blocks
And if you mount it manually?
mount -v /dev/sdg1 /mnt
--
If you can't laugh at yourself, others will gladly oblige.
8:03 p.m.
On Aug 31, 2014, at 6:55 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Aug 31, 2014, at 4:33 PM, Sudhir Khanger <sudhir(a)sudhirkhanger.com> wrote:
> On Monday, September 01, 2014 06:26:56 AM Ed Greshko wrote:
>> What do you mean by "scrubbed"?
>
> http://manpages.ubuntu.com/manpages/saucy/man1/scrub.1.html
>
>> Have you tried un-mounting and running fsck on the partition?
>
> Disk is pretty new and it was in working condition last time I tried it.
>
> sudo fsck /dev/sdb1
> fsck from util-linux 2.24.2
> e2fsck 1.42.8 (20-Jun-2013)
> storejet25m3: recovering journal
> storejet25m3: clean, 11/61054976 files, 3883091/244190208 blocks
Ideally boot from alternate media and run
e2fsck -f
It's usually best to fully comprehend the post before replying, and I only understood
this wasn't a problem with root fs until after replying. Anyway, the point is that
fsck without -f doesn't always ensure the filesystem is actually fsck'd, it may
just defer to the journal which may suggest the filesystem is clean. If so the fsck is
quick.
So I'd still umount it, and run e2fsck -f on that volume.
Chris Murphy
7:55 p.m.
On Aug 31, 2014, at 4:33 PM, Sudhir Khanger <sudhir(a)sudhirkhanger.com> wrote:
On Monday, September 01, 2014 06:26:56 AM Ed Greshko wrote:
> What do you mean by "scrubbed"?
http://manpages.ubuntu.com/manpages/saucy/man1/scrub.1.html
> Have you tried un-mounting and running fsck on the partition?
Disk is pretty new and it was in working condition last time I tried it.
sudo fsck /dev/sdb1
fsck from util-linux 2.24.2
e2fsck 1.42.8 (20-Jun-2013)
storejet25m3: recovering journal
storejet25m3: clean, 11/61054976 files, 3883091/244190208 blocks
Ideally boot from alternate media and run
e2fsck -f
Otherwise, if you're repairing root while booted from it you should boot in emergency
mode [1] but chances are that's already happening to you, if so:
e2fsck -f
Make a note of any major problems or unfixed problems, cell phone camera is good for this,
then
systemctl reboot -f
Chris Murphy
[1] Edit the grub menu entry, add this boot parameter: systemd.unit=emergency.target
7:42 p.m.
On 08/31/2014 05:33 PM, Ed Greshko wrote:
If you go back and read the thread you'd find that I'd asked
the OP to mount it manually with -v to see if there were any errors being reported. So,
it isn't odd at all.
Thank you. I'd been wondering if he had a specific need to mount it
that way. Now I know.
7:33 p.m.
On 09/01/14 08:22, Joe Z eff wrote:
On 08/31/2014 05:06 PM, Ed Greshko wrote:
> On 09/01/14 07:52, Ed Greshko wrote:
>> chown youruser:yourgroup /mnt/test
>
> Alternatively, you could make /mnt/test similar to /tmp
>
> chmod 1777 /mnt/test
>
I don't remember how this thread started, but I find it a tad odd that the drive is
being mounted in /mnt/test because the default for auto-mounting external media is in
/run/media/USERNAME, and if the drive has a label, it's mounted as
/run/media/USERNAME/LABEL. If the drive has an entry in /etc/fstab, you can mount it
anyplace you want, but before you mount the drive you have to create the mountpoint
manually and, if needed, set the permissions.
If you go back and read the thread you'd find that I'd asked the OP to mount it
manually with -v to see if there were any errors being reported. So, it isn't odd at
all.
The fsck fixed the initial problem that probably was the result of using "scrub"
on the partition. The fsck recovered the journal....which was probably the problem.
So, the problem with mounting RO is now fixed. Just giving suggestions on how the OP can
achieve the goal of using the drive without becoming root or using sudo. The
"fix" depends on how the OP intends the drive to be used.
--
If you can't laugh at yourself, others will gladly oblige.
7:22 p.m.
On 08/31/2014 05:06 PM, Ed Greshko wrote:
On 09/01/14 07:52, Ed Greshko wrote:
> chown youruser:yourgroup /mnt/test
Alternatively, you could make /mnt/test similar to /tmp
chmod 1777 /mnt/test
I don't remember how this thread started, but I find it a tad odd that
the drive is being mounted in /mnt/test because the default for
auto-mounting external media is in /run/media/USERNAME, and if the drive
has a label, it's mounted as /run/media/USERNAME/LABEL. If the drive
has an entry in /etc/fstab, you can mount it anyplace you want, but
before you mount the drive you have to create the mountpoint manually
and, if needed, set the permissions.
6:52 p.m.
On 09/01/14 07:34, Sudhir Khanger wrote:
It didn't do any good. I can't write to the disk without
superuser previleges.
Even if that would have made the disk writable I wouldn't want to use two
commands each time I hook up a usb disk. And it was working before anyways.
you are using a ext4 file system....
chown youruser:yourgroup /mnt/test
If you want to use a usb disk such that anyone that plugs it in can write to it then you
need to use ntfs or another of the wonderful MS filesystems types.
--
If you can't laugh at yourself, others will gladly oblige.
6:25 p.m.
On 09/01/14 07:19, Joe Z eff wrote:
On 08/31/2014 04:05 PM, Ed Greshko wrote:
> On 09/01/14 06:59, Ed Greshko wrote:
>> The selinux "warning" is fixed by "restorecon -R /mnt"
>
> I meant "restorecon -R /mnt/test" Missed your different mount point.
:-(
>
In this case it didn't matter because you used -R, meaning "recursive."
I prefer to be precise.
--
If you can't laugh at yourself, others will gladly oblige.
6:19 p.m.
On 08/31/2014 04:05 PM, Ed Greshko wrote:
On 09/01/14 06:59, Ed Greshko wrote:
> The selinux "warning" is fixed by "restorecon -R /mnt"
I meant "restorecon -R /mnt/test" Missed your different mount point. :-(
In this case it didn't matter because you used -R, meaning "recursive."
5:59 p.m.
On 09/01/14 06:53, Sudhir Khanger wrote:
Then I get this error. I tried setenforce 0 but that didn't
help.
sudo mount -v /dev/sdb1 /mnt/test
mount: /mnt/test does not contain SELinux labels.
You just mounted an file system that supports labels which does not
contain labels, onto an SELinux box. It is likely that confined
applications will generate AVC messages and not be allowed access to
this file system. For more details see restorecon(8) and mount(8).
mount: /dev/sdb1 mounted on /mnt/test.
And
mount | grep /dev/sdb
/dev/sdb1 on /mnt/test type ext4 (rw,relatime,seclabel,data=ordered)
So, it is now mounted RW.
The selinux "warning" is fixed by "restorecon -R /mnt"
--
If you can't laugh at yourself, others will gladly oblige.
5:53 p.m.
On Monday, September 01, 2014 06:40:05 AM Ed Greshko wrote:
And if you mount it manually?
mount -v /dev/sdg1 /mnt
Then I get this error. I tried setenforce 0 but that didn't help.
sudo mount -v /dev/sdb1 /mnt/test
mount: /mnt/test does not contain SELinux labels.
You just mounted an file system that supports labels which does not
contain labels, onto an SELinux box. It is likely that confined
applications will generate AVC messages and not be allowed access to
this file system. For more details see restorecon(8) and mount(8).
mount: /dev/sdb1 mounted on /mnt/test.
And
mount | grep /dev/sdb
/dev/sdb1 on /mnt/test type ext4 (rw,relatime,seclabel,data=ordered)
--
Sudhir Khanger,
http://sudhirkhanger.com
http://github.com/donniezazen
5:33 p.m.
On Monday, September 01, 2014 06:26:56 AM Ed Greshko wrote:
What do you mean by "scrubbed"?
http://manpages.ubuntu.com/manpages/saucy/man1/scrub.1.html
Have you tried un-mounting and running fsck on the partition?
Disk is pretty new and it was in working condition last time I tried it.
sudo fsck /dev/sdb1
fsck from util-linux 2.24.2
e2fsck 1.42.8 (20-Jun-2013)
storejet25m3: recovering journal
storejet25m3: clean, 11/61054976 files, 3883091/244190208 blocks
--
Sudhir Khanger,
http://sudhirkhanger.com
http://github.com/donniezazen
5:26 p.m.
On 09/01/14 05:32, Sudhir Khanger wrote:
Fedora 20 KDE Thinkpad T420i laptop has started mounting Transcend
StoreJet
25M3 as read-only. I tried remounting with rw but it is still mounted as ro.
The system is fully updated. I have recently scrub-ed the external drive to
prepare for backup.
[donnie@fedora ~]$ mount | grep /dev/sdb1
/dev/sdb1 on /run/media/donnie/storejet25m3 type ext4
(ro,nosuid,nodev,relatime,seclabel,data=ordered,uhelper=udisks2)
[donnie@fedora ~]$ ls -l /run/media/donnie/storejet25m3
total 16
drwx------. 2 root root 16384 Aug 31 12:55 lost+found
What do you mean by "scrubbed"?
Have you tried un-mounting and running fsck on the partition?
--
If you can't laugh at yourself, others will gladly oblige.
4:47 p.m.
Well, sounds like my problem with the SanDisk 16GB Xtreme sdhc flash,
which has already been extensively discussed in this list.
On 08/31/2014 03:32 PM, Sudhir Khanger wrote:
Hello,
Fedora 20 KDE Thinkpad T420i laptop has started mounting Transcend StoreJet
25M3 as read-only. I tried remounting with rw but it is still mounted as ro.
The system is fully updated. I have recently scrub-ed the external drive to
prepare for backup.
[donnie@fedora ~]$ mount | grep /dev/sdb1
/dev/sdb1 on /run/media/donnie/storejet25m3 type ext4
(ro,nosuid,nodev,relatime,seclabel,data=ordered,uhelper=udisks2)
[donnie@fedora ~]$ ls -l /run/media/donnie/storejet25m3
total 16
drwx------. 2 root root 16384 Aug 31 12:55 lost+found
3531
days inactive
3534
days old
44 comments
6 participants
participants (6)
-
Chris Murphy -
Ed Greshko -
JD -
Joe Zeff -
Sudhir Khanger -
Tim