I just installed KnoppMyth, and I have transfered some preexisting music files (MP3s and FLAC) to /myth/music. However, they do not show up in my music even after rescanning for new files.
Any suggestions?

Hi
Check to see who owns them.
Mike

mjl,
What do you mean by "who owns them"? I am new to Linux and Myth and am not quite up on the terminology. Thanks.

Hi,
Sorry, only had a few moments to give an idea. If you do (note the $ is the mythtv user prompt)
$ ls -al /myth
$ ls -al /myth/music
then you can see who "owns" them
drwxrwxr-x 98 mythtv mythtv 4096 Oct 24 20:42 music is what is returned from my system. This would apply to the other directories and files also. Not all things are owned by mythtv so let us know what you see and maybe help verify what you have is correct.

Mike

ls -al /myth gives:

drwxrwxr-x 3 mythtv mythtv 4096 Jan 21 07:05 music

ls -al /myth/music gives:

-rwx------ 1 root root 36718703 Jan 21 05:58 Phenomenon.flac

I believe that I am seeing that "root" owns the file while "mythtv" owns the folder. Do I need to get the file to be owned by "mythtv"? If so, is there a quick way to change it's ownership?

Not only that, but the permission structure is such that nobody (except root) has any access to that file.

You'll want something like:
Man chmod for more options

You _will_ want to fix the ownership and the permissions, but you will most emphatically _not_ want to do that.

Do this instead:

No offense meant here tjc, but on a standalone FE/BE, why not?

I have not found that opening the permissions to /myth/music (or /myth/video for that matter) leads to any more of a security issue than is already assumed by installing Knoppmyth. And that point has already been made on this forum (although I admit I doubt many folks have really considered the security implications of their KM boxen).

Am I missing something?

Hi,

It is always good to practice proper settings and procedures so that it becomes an automatic thing you don't have think about. It is like driving through stop signs, one day that unsafe moment will bite you.

Your KM box maybe behind a firewall but why not get in the habit of using proper permissions. Someday you may help a friend build one and he/she may not understand the need for a firewall on their KM box thinking it is linux so therefore safe.

I thank tjc for being kind and teaching us.
Mike

If you think file permissons are only for security, or even just safety, then you're missing the bigger picture. (I'm also ignoring the fact that ldanix may have adult or personal content on there and young children or snoopy roommates.) This is like asking why bother having a hierarchical file system when you can just put everything in one big directory with arbitrarily long file names. It's also almost, but not quite, as bad as MS-Windows blindly executing an email attachment because it has an .exe or .com extension.

File permissons are very much about categorization, intent, and communicating that intent.

Setting +x on a file tells you that it's an executable of some kind. Either a native binary or a script with #! magic up front to indicate what interpreter to use. This is as much a signal to the user as it is to the OS. It's also the part that makes me want to howl when I see someone propogating the evil "chmod 777" meme. (I'll get to the why in a minute.) More to the point, if it's not an executable, there is absolutely no benefit to file being marked +x. None. Zero. Zilch. Nada.

Setting go+w on a file tells you that it's a free for all of some kind. Today when any computer professional worthy of the name uses a revision control system for the type of file sharing that people used to use g+w for, it's an indicator that something very special is going on. The file is most likley a device, or a named pipe, or a Unix domain socket, or some kind of semaphore used with locking for safety. Again to the point of "non owner" users being able to access the file contents, there is almost never any need to make an ordinary file like video or audio data writeable. Other users just don't need to be able to write the file to have the full use of the contents, and if they're editing it, I'll argue (strongly!) that they should be working on a private copy.

Lets take a real world example. Developer X discovers that after a fresh install a file named "1" is being created in the root directory. Having seen this before he realizes that there's a redirection problem in one of the scripts. However since scripts have arbitrary names, how can he find them all to search through them? For starters scripts are (generally) executable, and they are not binaries. When you run the "file" command on a binary it says something like this:

They're pretty consistent this way. The results for script look very different but much less consistent:

Now, if you find all the executable files, and ignore the binaries, you can generate a list of the scripts and search them for the problem redirection:

Of course everytime developer X goes to do this he discovers that someone has been sloppy and marked a substantial portion of the ".gif", ".jpg", ".png", ... or even a whole directory tree as executable. (Grrrr...)

At the bottom "turning all the bits on" is like "cleaning" the windows of your new car by blowing them out with a 12 gauge shotgun. Sure it "works", but it also fills the interior with broken glass and shot pellets and shows a fundamental ignorance of the fact that those wondows are there for a reason (like keeping the bugs out of your teeth, and the weather out of your car). A bucket and sponge or a bottle of windex and some paper towels require a hair more effort, but do what you intended without the collateral damage.

Ahh, I see the problem. I did not intend to include the executable bit, so was a bit confused by your response. Sorry about that, must have been a slip 'o the fingers and I didn't catch it when I previewed