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
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
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?
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
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
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)
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"
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."
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.
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
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.
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.
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.
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.
On Aug 31, 2014, at 4:33 PM, Sudhir Khanger sudhir@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
On Aug 31, 2014, at 6:55 PM, Chris Murphy lists@colorremedies.com wrote:
On Aug 31, 2014, at 4:33 PM, Sudhir Khanger sudhir@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
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.
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.
On Mon, Sep 1, 2014 at 8:44 AM, Ed Greshko ed.greshko@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?
On 09/01/14 14:04, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 8:44 AM, Ed Greshko ed.greshko@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.
On Mon, Sep 1, 2014 at 11:44 AM, Ed Greshko ed.greshko@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@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@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
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?
On Mon, Sep 1, 2014 at 12:33 PM, Ed Greshko ed.greshko@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?
On 09/01/14 15:08, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 12:33 PM, Ed Greshko ed.greshko@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.
On Mon, Sep 1, 2014 at 12:41 PM, Ed Greshko ed.greshko@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@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@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?
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.
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.
On Mon, Sep 1, 2014 at 1:11 PM, Ed Greshko ed.greshko@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.
On 09/01/14 16:07, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 1:11 PM, Ed Greshko ed.greshko@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.
On Mon, Sep 1, 2014 at 1:37 PM, Sudhir Khanger sudhir@sudhirkhanger.com wrote:
On Mon, Sep 1, 2014 at 1:11 PM, Ed Greshko ed.greshko@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.
On Mon, Sep 1, 2014 at 1:43 PM, Ed Greshko ed.greshko@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.
On 09/01/14 16:13, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 1:37 PM, Sudhir Khanger sudhir@sudhirkhanger.com wrote:
On Mon, Sep 1, 2014 at 1:11 PM, Ed Greshko ed.greshko@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.
On Mon, Sep 1, 2014 at 1:50 PM, Ed Greshko ed.greshko@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.
On 09/01/14 16:25, Sudhir Khanger wrote:
On Mon, Sep 1, 2014 at 1:50 PM, Ed Greshko ed.greshko@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....
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
On Mon, Sep 1, 2014 at 7:01 PM, Ed Greshko ed.greshko@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.
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
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.
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....
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.
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.
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.
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.
-
Chris Murphy -
Ed Greshko -
JD -
Joe Zeff -
Sudhir Khanger -
Tim