CachyOS drive mount journey
I had another post and got some great advice, thank you to everyone who took the time, but I've learned so much over the last 2 days that I wanted to be more direct and clear since I'm still stuck. Mostly I just want to know if I'm on the right track, and if anyone had any advice. I don't just want to get things working, I'd like to understand why. After a lot of digging, I feel like I might be close to getting it.
I have 4 secondary internal drives, and 2 external. They all mount as root 777, I can access things but I also use Emby server. Emby can see everything, but can't write. So that said, here's how it started to where I'm at, does this sound like I'm heading in the right direction?
- CachyOS mounts to /run/media/user (the user folder has a lock on it) and I had to password/mount all drives at every reboot. I read something about /run being a temp folder so I looked into auto-mounting after some advice.
- I learned how to set up auto mount with gnome disk utility, which writes to fstab. Great! fstab hurts my brain after filling it up the last 2 days. I set them to mount to /mnt/drivename, and they auto mount at boot. So far so good!
- I can now access my drives, so I began setting up my server. No problem this time! Emby sees the directories and scans them. Finally! However even though I can rw on the drives, Emby sees them as read only. Bummer.
- Checking permissions, the drives are all mounted as root, with 777 permissions (which I suppose is why I can write to them but I don't get why Emby can't, maybe because it's a different user?).
- Time to get permissions! sudo chown does nothing. Still owned by root. Right click/permissions shows root:root, owner, group, other all can view and modify content, and it's all greyed out. 'Cause it's root, duh.
- More digging, the drives are NTFS! Apparently Arch mounts NTFS with root ownership, permanently. This makes sense! I think I found my problem! Maybe.
- Now I'm here, asking you wonderful nerds before I continue. I'm planning to change the mounts in gnome disk utility back to default (slider) and unmount and reboot. No idea if they'll mount to /run or /mnt. Next, I have ntfs-3g installed and plan to run
mount -t ntfs3 /dev/sdxY /mntthough I think I either need to create a drivename folder in /mnt or addmount -t ntfs3 /dev/sdxY /mnt/DRIVENAMEthe drive name to the end and it'll create it maybe?
The other thing that's bugging me is that gnome disk utility writes the mounts to fstab. I'm thinking if I do it this way, fstab will still have the old info and it'll cause issues? Putting the slider back to default probably won't just clear the fstab rules. That'd be too simple haha.
I'm totally not opposed to just reinstalling yet again and starting from scratch, if my plan will work. Any guidance is greatly appreciated!
EDIT: I think I got it! For anyone with the same issue, I added uid=1000,gid=1000 to the end of the options strings in gnome disk utility. I am now the owner of the drives, Emby can do what it needs to do, and the permissions stuck after a reboot! Now I just gotta look into why that worked haha.
EDIT 2: Spoke too soon. After a reboot they were ro for Emby again. I added rw to the drive options and it worked again. But after another reboot, no go again. Turns out after each reboot unmounting then remounting works. Not sure if there's a way to make this work. Maybe they mount too soon? I dunno, but for now it's functional.
non_burglar
in reply to Jack_Burton • • •777 is read/write/execute for owner, group, and world, respectively. It's the most permissive POSIX permission that can be set. If something can't write on a 777 umask, then either the filesystem is mounted read-only, or something is deeply wrong with the storage.
You probably have the clean unmount bit unset for the NTFS partition. This is trivial to bypass, but I would suggest not using NTFS in Linux, NTFS is not a great fs and Linux support is... OK.
Jack_Burton
in reply to non_burglar • • •Yeah, I'd prefer ext4 but the drives are large and full (made on Windows) and I have nothing to transfer to to reformat. They're staying NTFS for now. I've used sudo ntfsfix -d /dev/sdxY on them and it comes up all good.
How could I bypass it if that's the issue?
non_burglar
in reply to Jack_Burton • • •FauxLiving
in reply to Jack_Burton • • •Will create /mountname in /mnt and then mount the device on the created directory.
Instead of doing that you could just edit the fstab file and change the fileystem type to ntfs-3g(the package may be just ntfs on CachyOS so ymmv). Although, I suspect this is already done since you're able to access and read the drive.
You may need to add -o permissions so that standard Linux permissions are applied (TFM: linux.die.net/man/8/ntfs-3g), alternatively you can add 'permissions' to your current fstab entries, then remount the drives.
ex:
... show moreWill create /mountname in /mnt and then mount the device on the created directory.
Instead of doing that you could just edit the fstab file and change the fileystem type to ntfs-3g(the package may be just ntfs on CachyOS so ymmv). Although, I suspect this is already done since you're able to access and read the drive.
You may need to add -o permissions so that standard Linux permissions are applied (TFM: linux.die.net/man/8/ntfs-3g), alternatively you can add 'permissions' to your current fstab entries, then remount the drives.
ex:
How is Emby installed? In a container or are you running it on bare metal?
When you say it sees them as read only, what indicates this? A log? A GUI element?
Jack_Burton
in reply to FauxLiving • • •Just installed, no container.
If I try to change artwork, delete, etc, a popup comes up saying it's read only.
However, I think I got it set. I added uid=1000,gid=1000 to the end of the options string and Emby now has control.
FauxLiving
in reply to Jack_Burton • • •Yup, that'll do it.
Adding uid=1000,gid=1000 tells the NTFS mount driver “Present every file on this NTFS volume as if it is owned by UID 1000 and GID 1000.” The account running Emby is probably just your user account (guessing) so this did what you were trying to do with chown. Chown won't work without the 'permissions' option and a usermapping file to translate linux IDs to the SID's that NTFS uses, probably way more configuration than you need.
You should try to get off of NTFS ASAP. It'll be fine for media storage but some things (pc games, esp) really hate running off of NTFS. I know how unwieldy it is to shift the data around, but it will save you a lot of headaches going forward.
Jack_Burton
in reply to FauxLiving • • •Awesome thank you, I appreciate the rundown. I...sort of get it haha. I need to remount after reboot or they go back to ro, but it's functional at least.
I would love to, but it's just not in the cards for the foreseeable future. I'm all in on Linux and the NTFS drives are the last remnant of Windows. One day...
FauxLiving
in reply to Jack_Burton • • •You shouldn't need to remount if you added the options, they should be in the fstab file now so they'll be applied at every reboot. If it isn't doing that check the fstab file
To see what the relevant entry says. The options block is the block of text just before the two numbers at the end of the file.
Jack_Burton
in reply to FauxLiving • • •/dev/disk/by-label/Samsung /mnt/Samsung auto nosuid,nodev,nofail,x-gvfs-show,uid=1000,gid=1000,rw 0 0FauxLiving
in reply to Jack_Burton • • •That fstab entry is correct (assuming the by-label path is valid), you could change auto to ntfs-3g but it is likely detecting the correct type so that isn't needed.
If you can put it in the 'not working' and also in the 'working' state you can compare how it is mounted with
That'll show the options that the mounts are currently using, a quick thing that you can try unmounting and remounting
That should mount it with the options in the fstab file, you can confirm with the findmnt command.
If not, that doesn't work try umounting and then mounting with the options set explicitly:
and see if they show in findmnt.
Jack_Burton
in reply to FauxLiving • • •Awesome thank you so much. I was wondering about the auto option. I'll try changing that to ntfs-3g in gnome disk. I'm guessing I could also open fstab and change it manually but I'm not quite there yet haha. I just tried
findmnt -t ntfs-3gand there was nothing. I'm expecting to see something when I run it again after changing from auto.Edit: Changed one drive to ntfs-3g and rebooted.
findmnt -t ntfs-3gis still nothing, butsudo nano /etc/fstabdoes show it's ntfs-3g. Still had to remount for Emby to get write privileges. I then unmounted Samsung and ransudo mount -t ntfs-3g -o uid=1000,gid=1000,rw /dev/disk/by-label/Samsung /mnt/Samsung. fstab still shows auto on that one.FauxLiving
in reply to Jack_Burton • • •ou're Try just running findmnt, the type may be ntfs instead of ntfs-3g. The -t switch is saying to filter and only show 'ntfs-3g' mounts and it maybe called something else in your environment. The list will be a bit longer but you should be able to find the listing, it'll be the directory where your drive is mounted.
Did Emby work after this? You said you had to remount, what did you use to do that?
If you can get Emby to work, you can then look at findmnt to see how the working directory is mounted (which options/etc) and then you can update your fstab to have those options so that it will mount on startup.
Now's a good time!
Editing the fstab is the 'correct' Linux way of doing things, the GUIs can be convenient but they can also prevent you from learning how the system
... show moreou're Try just running findmnt, the type may be ntfs instead of ntfs-3g. The -t switch is saying to filter and only show 'ntfs-3g' mounts and it maybe called something else in your environment. The list will be a bit longer but you should be able to find the listing, it'll be the directory where your drive is mounted.
Did Emby work after this? You said you had to remount, what did you use to do that?
If you can get Emby to work, you can then look at findmnt to see how the working directory is mounted (which options/etc) and then you can update your fstab to have those options so that it will mount on startup.
Now's a good time!
Editing the fstab is the 'correct' Linux way of doing things, the GUIs can be convenient but they can also prevent you from learning how the system works (so when it later breaks, you have no idea where to start).
fstab is just a text file, there are 6 fields: . The way it tells the fields apart is through white space(a tab or space character).
If you're worried about breaking anything you can just make a backup:
If you break something, just restore it:
Jack_Burton
in reply to FauxLiving • • •Wow, that fstab info is great thanks! I've added it to my notes.
If you can get Emby to work, you can then look at findmnt to see how the working directory is mounted (which options/etc) and then you can update your fstab to have those options so that it will mount on startup.
Yes, it works as it should. I've done it twice, and remounted once with gnome disk and once in Dolphin. However, I'm wondering if it's an issue with installing Emby itself. Emby can access everything it should after remounting the drives, but the drive permissions are all user:user with 777 (which is probably why Emby can access it, it's permission is other?) There's nothing with permissions for user:emby like it should be, and sudo chown doesn't change the group. There's also no emby group option in the pulldown menu (when I was on Ubuntu I just used the pulldown to change the group permission). I went to make sure and ran groupadd emby but it said there's already a group emby.
... show moreWow, that fstab info is great thanks! I've added it to my notes.
If you can get Emby to work, you can then look at findmnt to see how the working directory is mounted (which options/etc) and then you can update your fstab to have those options so that it will mount on startup.
Yes, it works as it should. I've done it twice, and remounted once with gnome disk and once in Dolphin. However, I'm wondering if it's an issue with installing Emby itself. Emby can access everything it should after remounting the drives, but the drive permissions are all user:user with 777 (which is probably why Emby can access it, it's permission is other?) There's nothing with permissions for user:emby like it should be, and sudo chown doesn't change the group. There's also no emby group option in the pulldown menu (when I was on Ubuntu I just used the pulldown to change the group permission). I went to make sure and ran groupadd emby but it said there's already a group emby.
As it is right now it all works after remounting, that said the drives that should say ntfs-3g in findmnt say fuseblk, in fact all the NTFS drives are fuseblk.