Hello J-Kappes,
It sounds to me like the permissions are wrong on /run/media/YOURNAME, /run/media/YOURNAME/Home(Share), or all. Probably owned by root.
1 Like
IF my hunch is correct, they may actually be mounting at boot.
Well, if the mount points are created by systemdthat is for sure. But like @arvidjaar points out, we have not really an idea what that file manager is used for or what is âclickedâ, etc.
But we need to see direct after boot if they are mounted or not (by e.g. mount or lsblk -f) and when hey are not we need a list of the log.
The file manager link is a âred herringâ ⌠that it prompts for a password and works afterward tells us that it points to the right place, whatever that may actually be.
Of course, the OP could make things more transparent:
ox@orca$ cat /home/ox/.config/gtk-3.0/bookmarks
file:///home/ox/Documents Documents
file:///home/ox/Downloads Downloads
file:///home/ox/Music Music
file:///home/ox/Pictures Pictures
file:///home/ox/Videos Videos
file:///xtra/av0 av0
file:///xtra/av1 av1
Both nautilus and nemo use this file to read and store bookmarks. Probably thunar as well.
They were mounted as expected once I changed the mount point to /mnt/. I assumed it would work in run/media/myname/ because it did on BlendOS. I had picked that spot precisely because manually mounting them placed them there.
It happened to me with thunar. I labelled all partitions for clarity on thunar sidebar and automatically mounted partitions in /run/media/user⌠with root as owner of the folders. I changed the owner to my user and it worked.
As workaround I suggest the OP this:
Create folders for the different partitions inside /mnt, and be sure permissions are correct (your user as owner).
modify fstab and associate each uuid with the correct folder in /mnt (that folder as mount point).
when you check everything is working correctly you could delete those folders inside /run/media/user/⌠BE SURE ANY FOLDER YOU DELETE IS EMPTY BECAUSE THE PREVIOUSLY ASSOCIATED PARTITION IS NOW MOUNTED IN /MNT BECAUSE YOU PUT IT IN FSTAB.
Hello @sidler_bot ,
I not sure I completely follow, but there is one mistake in what you have written. It does not matter who owns an empty folder prior to its use as a mount point. To change the ownership of a filesystem, the ownership of the folder (aka: directory, mount point) must be changed after mounting. (I think it is possible to explicitly declare ownership in /etc/fstab, or manually via the âmountâ command, I need to try both!)
root@orca# pwd
/xtra
root@orca# ll
total 8
drwx------ 21 ox ox 4096 Jul 25 23:32 av0
drwx------ 39 ox ox 4096 Jul 30 18:24 av1
root@orca# umount av1
umount: /xtra/av1: target is busy.
root@orca# umount av1
root@orca# ll
total 8
drwx------ 21 ox ox 4096 Jul 25 23:32 av0
drwxr-xr-x 2 root root 4096 Jun 13 21:45 av1
root@orca# mount -a
root@orca# ll
total 8
drwx------ 21 ox ox 4096 Jul 25 23:32 av0
drwx------ 39 ox ox 4096 Jul 30 18:24 av1
root@orca#
Setting up mount points is fairly easy, but tricky if you have never done it before, or you only do it once every few years.
Cheers
It is quite simple. mounting builds the directory tree of a Unix/Linux system. After this is complete, one should forget about how the directory tree is build up.
Then there is the fact of ownership (by user and group) and the permissions of every file (a directory is also a file). They are there (correct or not) on every Unix/Linux file system.
Problems arise when using non-Linux file systems. They do not have the file ownership and permissions. For the sake of compatibility and usability inside a Unix/Linux file system, they are faked. You can influence the faking with file system options of the mount. Either with the mount command, or preconfigured in /etc/fstab. So those are only relevant for non-Linux file systems (and the man pages are very clear about that).
Thus the saying âchange the ownership of a filesystemâ is in fact nonsensical. You have and can change the ownership of files. For a non-Linux filesystem you can set the ownership for all files on the file system (the same), after that you can not change them as long as the file system is mounted (nor can you change the permissions, something the people try to do time and again in vain).
Hi @hcvv ,
You really lost me with âmounting builds the directory tree âŚâ. It makes a pre-existing structure available, no? Or do mean non-native filesystems? For ext4 and friends, the structure results from filesystem creation, e.g. mkfs.
ânonsensicalâ is a bit harsh, but âfilesystem ownershipâ is certainly more of a metaphor than a reality. I have to agree with that, at least in the strictest technical sense. I think the phrase âdevice ownershipâ is more accurate, though the underlying block device is usually owned by root. Prior to this discussion, I could not imagine why I would even want or need to change it.
But then I read about the owner option in mount(8):
The owner option is similar to the user option, with the restriction that the user must be the owner of the special file.
Does âspecial fileâ mean the underlying block device?
I have changed the ownership of the character device that represents my keyboard to allow firmware customization through VIA. So why not a block device?
Luckily, I do have a spare disk to play with ⌠so perhaps I will learn something new today 
.
The problem i had is thunar, guess thunar-volman, mounted partitions that wasnât in fstab as read only. I did different by labelling all my partitions in order to recognize them all quickly when in thunar side panel, and changing permissions of folders in /run/media/user/⌠(donât remember if populated or not) changing owner of the folders to my user because it works for me because my small controlled environment.
But I think the workaround could be a solution for everybody struggling with this issue. Sorry my lack of knowledge and thanks for the feedback.
I am not talking at all about the ownership of the device files.
Sorry, very basic.
Unix/Linux has itâs files stored in three structure of directories (thar start with the âroot directoryâ, wriiten / ).
There are more operating systems that have such a structure, but e.g. Windows has more of those, where Unix/Linux has only one. As said, starting with /.
To âmakeâ or âbuildâ this tree at boot so it is available to system and users there is the concept of âmountingâ. It means that at least one file system must be mounted at /. Such a file system has in itself also the directory tree structure. The system needs at least one file system and beacuse it is mounted on / it is know as âthe root file systemâ.
More file systems can be added to this tree. They can be added to the tree at each directory (node) in that tree. Yes, by mounting. The reason the have different file sytems at different mount point can be manifold and change in importance over time. Long (well, not so long) ago disk were small and files, even within the part needed for the system (let alone for âuser dataâ had to be spread over disks. The need to use different types of file system (each has type has itâs pros and cons) for different types of data (e.g. system vs. database). The need to seperate e.g. user data from system data (the famous /home on itâs own file system), etc., etc.
BTW, this is also explained at the very beginning of that mount man page you mention.
Thus, during boot, the directory tree is build by mounting at least one, but possible more file systems.
Those file systems have no âownerâ. The files, including directories have owners.
Please read this text in itâs context. It has nothing to do with file ownership (let alone file system ownership) of the (to be) mounted file system. This is in the section Non-Superuser mounts about who may mount something.
And yes, that is about the ownership of the device file that contains the file system to be mounted.
And again today thanks to the advent of downloadable movies in Ultra High Definition :).
Thanks for the explanation.
Hello,
I did learn something new today. A new answer to the original question. An improved answer? I donât know yet.
For testing, I created a new ext4 filesystem on /dev/sdh with the fs_label âavxâ.
root@orca# ll /dev/sdh
brw-rw---- 1 root disk 8, 112 Aug 8 11:11 /dev/sdh
root@orca# blkid /dev/sdh
/dev/sdh: LABEL="avx" UUID="74efbdf6-1dc7-4348-b236-4b509b84c155" BLOCK_SIZE="4096" TYPE="ext4"
root@orca# ls -ld /xtra/avx
drwxr-xr-x 2 root root 4096 Aug 8 08:59 /xtra/avx
root@orca# mount /xtra/avx
root@orca# ls -ld /xtra/avx
drwx------ 4 ox ox 4096 Aug 8 11:03 /xtra/avx
root@orca# tail -13 /etc/fstab
##
## Mount at boot ... x-gvfs-show is not required, but causes the fs_label to be shown in a file manager's sidebar.
## sidebar-displayed for nemo, thunar, and nautilus (if it is usb, "Other Locations" for drives on the sata bus)
## If the file system lacks a label, the display entry will be along the lines of "750 GB Volume".
## The mount(8) man page states "The suggested format is X-appname.option", but "x-appname.option" does work.
##
#UUID=74efbdf6-1dc7-4348-b236-4b509b84c155 /xtra/avx ext4 X-mount.owner=ox,X-mount.group=ox,X-mount.mode=700,data=ordered,x-gvfs-show 0 2
#UUID=74efbdf6-1dc7-4348-b236-4b509b84c155 /xtra/avx ext4 x-mount.owner=ox,x-mount.group=ox,x-mount.mode=700,data=ordered,x-gvfs-show 0 2
##
## Mount as needed, in which case the x-gvfs-show option is more relavent, though not required.
##
UUID=74efbdf6-1dc7-4348-b236-4b509b84c155 /xtra/avx ext4 noauto,X-mount.owner=ox,X-mount.group=ox,X-mount.mode=700,data=ordered,x-gvfs-show 0 0
#UUID=74efbdf6-1dc7-4348-b236-4b509b84c155 /xtra/avx ext4 noauto,x-mount.owner=ox,x-mount.group=ox,x-mount.mode=700,data=ordered,x-gvfs-show 0 0
You are hijacking the topic. When you have a problem/question please start a topic of itâs own.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.