Transfer media from Linode to block storage volume?

Hello,
It sounds like you're executing all the chmod commands as a non-root user. If this is the case, that will likely fail, due to the fact that you need root permissions to mount the volume, I do believe. If you're only using the volume with a specific user, I would suggest that you change the ownership of the mounted volume as the owner of the user you're dealing with. If your user is media and its group is media, for instance, do this as root or a user with sudo permissions:

# chown media:media -R /mnt/ca.plex.volume
# chmod 755 -R /mnt/ca.plex.volume

Once you've done that, you ought to then be able to create directories and files as you wish, modify their permissions, etc.

I hope that helps.

Blake

I managed to allow myself to create the folders now. The problem I am now facing is that when I attempt to move(MV COMMAND) media folders/files from the main server into the volume I get the following error….

Status: Renaming '/home/plex/plex/media/shows/Spider-Man-TAS' to '/mnt/ca.plex.volume/shows/Spider-Man-TAS'
Command: mv "Spider-Man-TAS" "/mnt/ca.plex.volume/shows/Spider-Man-TAS"
Error: mv /home/plex/plex/media/shows/Spider-Man-TAS /mnt/ca.plex.volume/shows/Spider-Man-TAS: received failure with description 'Failure'<

My Plex Media Server is also not showing any folders/files when attempting to add an additonal folder to the library files. When I attempt the /mnt/ directory appears empty for PMS and even though I manually type in the correct /mnt/ca.plex.volume/movies adding it to the list of folders is not changing anything.

@tech10 --

You write:

It sounds like you're executing all the chmod commands as a non-root user. If this is the case, that will likely fail, due to the fact that you need root permissions to mount the volume, I do believe. If you're only using the volume with a specific user, I would suggest that you change the ownership of the mounted volume as the owner of the user you're dealing with. If your user is media and its group is media, for instance, do this as root or a user with sudo permissions

You don't need to be the super-user to change the permission of a file or directory. You just have to be the owner…or a member of the group that the owner belongs to. Becoming the super-user every time you get frustrated by file system ownership is a very bad habit that is dangerous to the long-term stability of your system and is even harder to break.

-- sw

@stevewi
You're correct about that, but to change the ownership initially, can't be done unless you're the super user or have sudo permissions. Once that's done, you can chmod without any problems without being the super user.

@stevewi
I was wondering if you would like to contribute/share the method that you would recommend using since I was able to fix the original permission errors when attempting to create those new directories on the mounted block-data storage volume by following @tech10's suggestion.

I have always been baffled by the file-system's permission structure. I have been using the Linux operating system as an end-user for at least 10+ years yet have never fully understood what I was doing when working with file-system permissions and the related terminal commands. I have
always or at least often been using the sudo command if I have needed to elevate the authority of my limited-user account for executing commands.

I had actually spent literal years not understanding how dangerous it was to exclusively use the root account for everything. I eventually understood that you could create limited-user accounts and elevate their authority by adding them to the sudo group. I think that I should take a look at which groups exist on my server and attempt to discover those which relate to the PMS. Especially when I consider that this is the first time running a Plex server that didn't use my own physical desktop/hardware as the server itself. Lin doe has given me such an amazing chance for messing around and understanding more about the way servers and computers function in general.

@ReclusiveOak --

You write:

I was wondering if you would like to contribute/share the method that you would recommend using since I was able to fix the original permission errors when attempting to create those new directories on the mounted block-data storage volume by following @tech10's suggestion.

I didn't say you should never use super-user privileges…only that you should be sparing with them. The prevailing wisdom seems to be that using super-user privileges are as common as getting a glass of water. If that's your attitude, you're going to do serious damage:

cd /
rm -r *

As far as the file system goes, there are only three things you need to remember:

• Files two levels of ownership related to your login: user and group. Which user/group a particular login belongs to is stored in /etc/passwd. A user may belong to more than one group -- thus giving that user some level of privilege on files belonging to that group. For example, my login user/group is stevewi/stevewi…but I also belong to groups sudo (so I can use the /usr/bin/sudo command effectively) and mail (so I manage files related to the mail server).

• Files have 3 groups of permissions: user, group and other. user and group are explained above. other is everyone else.

• Each of user, group and other has a triple of permission: read, write and execute (called r, w and x). These are pretty explanatory…

All of this is explained with detailed examples here: https://linuxhandbook.com/linux-file-permissions/

I've been a Unix/Linux user for a very long time. I can guarantee from personal experience that the better you know this stuff, the more successful your endeavors will be. Ignorance of file permissions and ownership are the source of a lot of problems posted here.

-- sw

P.S. In contrast, the Windoze file system (NTFS) has hundreds of different combinations of file ownership/permission…thousands if your Win machine is connected to a Windoze Server.

@tech10 --

There's a feature of su(1) that allows you to become other login accounts besides the super-user… Here's an example I use all the time:

su - mail
Password:

True, I'm using su(1) and I have to have the privilege to use it but the point here is that I'm NOT the super-user…and I can't do silly stuff that can do real damage (note that I can still do damage…just not catastrophic, the system-won't-boot damage).

It's also useful for running/testing a cron(8) job or other program/script that's supposed to run in the mail login. If you test your program/script while being the super-user, it will almost always work because the super-user can do anything. Not so with mail for example… Running/testing something in the context of the account in which it's supposed to operate normally will expose those things.

I use this most often to add group write/execute permissions to a file owned by the group mail. Once done, I can manage the file using my normal stevewi login because stevewi is also a member of group mail. Ditto for www-data (on Debian/Ubuntu…probably www in other distros).

The moral of this story is that group permissions are your friends and modifying them according to your needs is not nearly as unsafe as making files readable/writable/executable by the world (0777 or a+rwx…whichever flavor you prefer). Using group logins is infinitely preferable to becoming the super-user at the drop of a hat.

-- sw