I had my media all stored on a Windows machine when I used Kodi, using NTFS. Then, I switched to Plex and Linux, but since the 10TB array was already NTFS, I chose to keep it as NTFS and mounted the array at /disks/PlexMedia with read/write permissions. I have the array mapped to my Windows laptop where I download torrents so it can unzip the torrents directly to the Plex folder on the array. Everything is working. Mostly.
Now what bugs me is that it seems to be a workaround that I’m using. I cannot change owner or file permissions on the NTFS volume as far as I know, since permissions are set up at mount time.
I’m thinking of changing the array to ext4 so I will have control of ownership and permissions and so it will “play nice” with Linux commands. However, will that create additional problems with Windows when I copy files from my Windows machine to the newly mapped ext4 array? In other words, does ext4 work well with Windows shares?
I read another post on here about how NTFS-3g is a poor implementation and is prone to fragmenting if I read it correctly. So would using the native ext4 benefit me more because of Linux compatibility or would that compatibility cause more share issues in Windows than it’s worth?
In the long run, I’d like everything to run on Linux and never worry about Windows shares again, and maybe it’s possible with Wine, but there are a few programs that have no Linux equivalent, so I haven’t bothered switching to Transmission or Deluge because I still “need” Windows.
ext4 is a filesystem it stores files and metadata like owner user, owner group, permissions etc. It’s got nothing to do with deciding how to authenticate users locally, or over the network or how to interpret what Windows is asking it to do.
There’s multiple ways to do the copy, using Linux from a Windows share, and using Windows onto Samba backed by ext4.
In the first case, you have your Linux user doing the copy generating files owned by some user:group, and typically being managed by 16bit rwxrwxrwx permissions from that point on (typically). I’m just mentioning this because it’s simpler to imagine.
In the latter case, a user over a network authenticates themselves to the Samba server, and it’s Samba’s job to map users and their permissions onto local files. (And it can be configured to store permissions using extended file attributes that ext4 and many others support).
I’m guessing in a home setting, you don’t care about permissions particularly, or about modifying user attributes in your windows active directory to be able to map Linux users to Windows accounts, as long as you can mount the Samba share and throw files into a directory where Plex can read them you’re good? You might as well use FTP ?
There’s documentation on the Samba wiki. You’re most likely after a standalone host, posix acls use case.
Exactly. Everything is local only. As it stands, I have the NTFS array mounted with full R/W permissions for everyone. The few things that are bugging me was that I had to move the default mount from /media to a mount point I made up at /disks. This also made the array listed in the GUI under Computer unclickable (Unable To Mount). I can navigate to /disks and access it just fine, but that just doesn’t seem how it’s supposed to work.
Thanks for the quick, detailed response. I will look into POSIX right now.
I’m not sure what commands are giving you errors, but maybe the /disks/ folder you created is “owned” by root.
It might be as simple as unmounting the array, chown -r the folder to your user:group (or the plex user:your group, or vice versa?) ((then remounting))
I don’t know for sure, but it can’t hurt!
If not, let us know what command/error you are getting?
I didn’t know I could do that. I tried changing ownership with it still mounted and it didn’t change, although it never gave me an error. I chalked it up to being NTFS.
This is what I have been suspecting. I just finished setting up a system for my neighbor (the exact same way I set mine up, only on a single drive) but I will definitely go ext4 next time.
I’m getting this because it is already mounted, but it would be nice to still be able to click on that drive instead of navigating to /disks/PlexMedia. Just a minor thing really.
That is what I tried many times before and the owner never changed. Did you say I needed to unmount the drive first?
EDIT: I don’t want to waste anyone’s time. Plex is working, file sharing is working; right or wrong, I’ve accomplished my original goal lol. I’ll try anything you guys think will work though.
2.) Now change the owner of the folder/mount point to whatever users and groups need to have access.
sudo chmod -r tabun:PlexGroup /disks/PledMedia
3.) Now remount the share.
sudo mount -a
or
sudo mount /disks/PlexMedia
If everything works but you are having issues with your GNU/Linux user browsing to the folders, the above will help as long as you used the correct user and or group since your mounted permissions show as read/write/execute for the user, read and execute for the group, and execute for all others.
Did you mean “sudo chown -R tabun:plex /disks/PlexMedia”
because what you put here isn’t working. I tried the chown and it DID change the owner & group from root:root to tabun:plex but double clicking the drive icon in the desktop explorer still gives the same error.
I’ll have to play with this on my system now because my neighbor is expecting this media server today.
Thanks.
EDIT: Interestingly, after the remount, the owner:group are both back to root
users give any user that is part of the users group to mount and unmount the partition, exec allows all users to execute binaries.
After that, you need to look at the Samba settings to see how you are actually accessing the share.
Another thing to look at is if the dirty bit is flagged on your NTFS partition, if it is, a common behavior is to set it to root and root owned because there is a potential for data loss. You would either need to boot into a Windows environment for scandisk to fix this or use the fschk.ntfs tool to scan and clean the drive. This dirty bit warning will usually alert during a user initiated mount, or in dmesg during the boot process if auto is set in fstab.
?
