Amarok/Community/Samba: Difference between revisions

From KDE Community Wiki
(move page from ako wiki, needs updating)
 
m (fix typos)
Line 1: Line 1:
{{I18n/Samba}}
== The Problem ==
==The Problem==


You have your music files on a remote computer, and you share these files via samba/windows file sharing. The shared files may be read only or writeable by you, and you have them mounted on your local filesystem. You can access the files just fine there and play them, but they cannot be added to the collection. Adding silently fails, is very slow, or music gets added but cannot be played.
You have your music files on a remote computer, and you share these files via samba/windows file sharing. The shared files may be read only or writeable by you, and you have them mounted on your local filesystem. You can access the files just fine there and play them, but they cannot be added to the collection. Adding silently fails, is very slow, or music gets added but cannot be played.


==The Solution==
== The Solution ==


The solution depends on how the music is shared.
The solution depends on how the music is shared.
Line 21: Line 20:
*#Mount the share in read-write mode, as you always did. Use this new mount point to do everything except using it for amaroks collection.
*#Mount the share in read-write mode, as you always did. Use this new mount point to do everything except using it for amaroks collection.


==Rationale==
== Rationale ==


Above results were found a trial-and-error basis. It seems that the Amarok indexer reads the permissions for the owner of the file, even if your user is not the owner. It expects these permissions to work and procedes accordingly. The filesystem returns different permissions because you are not the owner. You can solve this by making sure that everybody has the same permissions as the owner. Of course, these permissions have to work out on the server as well, so if you mounted the share rw for everybody but you actually only have read access, things will not work. The last solution offered is the most elegant, because only your user has the permissions which are needed.
Above results were found a trial-and-error basis. It seems that the Amarok indexer reads the permissions for the owner of the file, even if your user is not the owner. It expects these permissions to work and proceeds accordingly. The filesystem returns different permissions because you are not the owner. You can solve this by making sure that everybody has the same permissions as the owner. Of course, these permissions have to work out on the server as well, so if you mounted the share rw for everybody but you actually only have read access, things will not work. The last solution offered is the most elegant, because only your user has the permissions which are needed.


==Making the solution permanent==
== Making the solution permanen t==


If the above worked for you, you probably don't want to mount the share everytime you start you computer. You should add the appropriate information to /etc/fstab. This file defines which filesystems are mounted at boot. Fstab had the following layout:
If the above worked for you, you probably don't want to mount the share every time you start you computer. You should add the appropriate information to /etc/fstab. This file defines which filesystems are mounted at boot. Fstab had the following layout:
  devicename mountpoint filetype options dump pass
  devicename mountpoint filetype options dump pass
''devicename'' is your ''//server/share''<br>
''devicename'' is your ''//server/share''<br>

Revision as of 14:35, 25 October 2012

The Problem

You have your music files on a remote computer, and you share these files via samba/windows file sharing. The shared files may be read only or writeable by you, and you have them mounted on your local filesystem. You can access the files just fine there and play them, but they cannot be added to the collection. Adding silently fails, is very slow, or music gets added but cannot be played.

The Solution

The solution depends on how the music is shared.

  • Create a mount point: http://ubuntuforums.org/showthread.php?p=1734713
  • If you have a read-only share, make sure that the files are mounted read-only for all users, including root. You can achieve this by mounting the share on the command line as root:
mount -t cifs -o file_mode=0444,dir_mode=0555,guest //server/share /path/to/mount-point

You may have to add some sort of user authentication if your share needs a password. fmask=444 gives owner, group and other read permissions and dmask=555 gives them read and execute permissions for directories. guest mounts the share without any authentication. If you need to authenticate for acces, replace guest with username=remote-user. Pressing enter will prompt you for a password. You can change the ownership of the mount by adding uid=localuser,gid=groupname behind 'guest'.

  • If you have a writeable share, you can mount it the same way as for a read-only share, but you will not be able to change tags and the like.
  • If you have a writeable share and you want to edit tags there are two things you can do:
    1. Mount the share writeable by everyone but still owned by root. You probably don't want to do this because other users can write/edit your songs as well:
mount -t cifs -o file_mode=0666,dir_mode=0777,guest //server/share /path/to/mount-point
    1. Mount the share writeable and owned by you. Access for other users is your own choice, but in the example we give them read only access.
mount -t cifs -o file_mode=0644,dir_mode=0755,uid=localuser,gid=groupname,guest //server/share /path/to/mount-point
  • There is a special case in which these solutions don't give good results: In the case that you have a writeable samba volume with read-only files on it that you want to add to your collection, mounting it read-only forbids you to change files you should be able to change and mounting in read-write mode doesn't solve the problem, because amarok still gets unclear information from the file system.

    Instead, you have to combine the two solutions from before:
    1. Mount the share read-only for every user including root, as described above. Use this volume for amarok. You will not be able to edit tags, of course.
    2. Mount the share in read-write mode, as you always did. Use this new mount point to do everything except using it for amaroks collection.

Rationale

Above results were found a trial-and-error basis. It seems that the Amarok indexer reads the permissions for the owner of the file, even if your user is not the owner. It expects these permissions to work and proceeds accordingly. The filesystem returns different permissions because you are not the owner. You can solve this by making sure that everybody has the same permissions as the owner. Of course, these permissions have to work out on the server as well, so if you mounted the share rw for everybody but you actually only have read access, things will not work. The last solution offered is the most elegant, because only your user has the permissions which are needed.

Making the solution permanen t

If the above worked for you, you probably don't want to mount the share every time you start you computer. You should add the appropriate information to /etc/fstab. This file defines which filesystems are mounted at boot. Fstab had the following layout:

devicename mountpoint filetype options dump pass

devicename is your //server/share
mountpoint is your /path/to/mount-point
filetype is cifs
option is everything that follows -o in the examples earlier, for example
fmask=644,dmask=755,guest,uid=your-user-name,gid=groupname,guest. If you need to provide a password for the share, create a file with username = your-user-name on the first line and password = your-password on the second line. Change the permissions on this file so that only you can read it (and therefore the password), and specify credentials=filename as one of the options.
dump and pass can be set 0 0.
Add all the information on a new line in /etc/fstab, like so:

//server/share /path/to/mountpoint cifs uid=localusername,gid=users,guest,fmask=444,dmask=555 0 0


Replace the server, share, etc as appropriate, and make sure the above is on one line in the file.

Mounting shares on Windows boxes

On Windows 2k/XP/Server shares it is important to mount them as cifs. cifs can handle much more files in directories and interacts better with the Microsoft software. Moreover it is important to set iocharset=utf8 because Windows uses Unicode for their filesystem since Windows 2000. This way you are able to use special characters abroad ASCII in your filenames without running into problems. An example line for /etc/fstab:

 //server/share /path/to/mountpoint cifs iocharset=utf8,uid=localusername,gid=users,guest,file_mode=0444,dir_mode=0555 0 0