Proper Permissions & Ownership for Synced Directories on Linux Machine

I am very inexperienced when it comes to using a command-line interface, Linux, and the concept of folder/directory permissions (among many other administrator-type things).

I previously installed Syncthing on a machine running Ubuntu Server, and it worked very well for syncing my game server backups to my desktop PC.

Every time I want to do something new with that machine, I research online, try to make sense of what I find, and write out all the steps I take so that I will be able to easily repeat them in the future. I just like to get things running on the machine and leave it alone – I don’t have a good brain for command-line computing. I basically write a script (instructions) for myself to follow to set things up, and then follow the script every time I need to do it again. …But it’s OK, because I wasn’t trying to impress you anyway!

I am now updating my instructions for installing Syncthing along everything else on my server machine, with plans to reinstall everything and additionally set up a Plex media server. I imagine Syncthing will work great for transferring files to the media server from my PC and will allow me to have two identical copies for backup purposes.

However, this time around I am updating my instructions to make the server machine as secure as possible, including establishing the proper directory permissions, and I just can’t wrap my head around how that works.

At least one guide I found online for installing the Plex media server said I MUST set the user named “plex” as the owner of the directory containing my media library, in addition to all of its subdirectories (by running sudo chown -R plex: [media directory] ).

I am afraid that if the “plex” account is the owner of the entire media library, Syncthing will not have access to the files and subdirectories and will not be able to sync them.

I suppose I could set the permission of the media directory so that ANYONE has full permission to access its contents, including Syncthing, but my research seems to indicate this is not a good idea. I don’t know what permission level is appropriate for my media library directory – I had figured 700, but now I am not sure.

I don’t even know if Syncthing has its own user account by default, like Plex apparently does, which I could perhaps put into a group with the “plex” user and then somehow give that group ownership of the media library directory. But then would I be able to access the contents myself, since my own account is no longer the owner, or do I need to add myself to the same group along with the “plex” user and “syncthing” user?

Or, will I be able to access the contents of any directory I don’t own by typing “sudo” in front of cd, or when running a program that needs to access those folders?

Furthermore, I don’t know what happens with newly added content AFTER the “plex” user becomes the owner of my entire media library and all its subdirectories. Every time new content is added to my media library, which would normally be via a Syncthing transfer from my PC, do I have to “chown” that content to the plex user again, every time? (Sorry, I know that question has nothing to do with Syncthing itself.)

My goal is simply to maximize security or follow best practices while allowing Syncthing and Plex to run smoothly, and to be able to access the media directory and files myself when necessary.

I could probably tinker and figure some of this out for myself, but I’m really just hoping to get things right the first time and not spend a lot of time scratching my head and trying to keep track of mistakes and fix them. It’s just the way my brain works (or doesn’t work). And I don’t know what is best practice, what is normal to do, or what potential problems could arise down the road from my decisions.

I’d just like to get it right, set it, and forget it.

I appreciate any help. Thank you!

If I use “sudo” when I run a program, does that give it access to any directory on the machine? Is that a wise thing to do? What about programs/services that run at boot – how to I ensure they have access to a directory that is not owned by the program’s own user account?

You can use group permissions, so the plex user and syncthing user can be in the same group, and the same group has all permissions on the folders. I am pretty sure you can find information on the internet how to do this.

Thanks! So just to confirm: When I install Syncthing, will a user named “syncthing” automatically be created? Is “syncthing” its name?

That depends on how you install Syncthing and from which source. “Our” packages from GitHub and don’t create a user automatically but rather assume you will run syncthing under your regular user account. You can do as you please, though.

Thank you. So if I run Syncthing manually, it will have the same file/directory access as my own user account? What if it is run automatically at boot by enabling the Syncthing service?

If I want to run Syncthing at boot, will I have to manually create a “syncthing” user (and then add it to a group with permission to access the media library)? And then somehow get the Syncthing service to run as the “syncthing” user?

All of these are general Linux permission questions and depend on how your system is setup. Syncthing will act like any other program on your machine, creating files owned by the user it’s run as.

Thanks. After some back-and-forth in the Plex forum, where I posted similar questions, I seem to have concluded that in my case restrictive file/directory permissions are not necessary. I am the only human user on the machine, and apparently Linux is unlikely to be hacked, so I don’t see any reason for restrictive permissions if it makes things unnecessarily complicated for me. I concluded that I probably do not need to worry about restrictive permissions.

Does that seem like a reasonable assessment in my use case?

Here is the link to my post in the Plex forum, for anyone who is curious:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.