can't access files since 4.4.2 update

[brofjst 0]

Hi.
Since the new update i can't access to my files, but i can watch them through emby
The files are stored in /var/lib/emby/library

permission on /var/lib/emby: lrwxrwxrwx  1 simo    root      12 Apr 22 16:34 emby -> private/emby
simo is in the emby group

Edited May 16, 2020 by brofjst

[Luke 42077]

 

 

i can't access to my files

Hi, what exactly do you mean by this?

[brofjst 0]

i can't open the folder with the file explorer and i can access to it only with root permission
https://i.imgur.com/lg9CBGh.png

[alucryd 315]

What distribution are you using?

[brofjst 0]

Arch Linux

[alucryd 315]

The latest update hardens the systemd service using DynamicUser. Placing user files in a `/var/lib` subdirectory is very bad practice, `/var/lib/emby` is reserved for the emby system user to write to, and this user is now created dynamically. The uid and gid of the directory is recursively changed with each service restart.

 

Please move your library elsewhere and make sure it is world-readable, if you don't want to rescan everything you can just drop a symlink to it in `/var/lib/emby/library`.

[brofjst 0]

i have some issues with the permission of the filesystem ntfs

mounted by fstab with these parameters:
UUID=myuuid  /home/simo/dati_4TB   ntfs-3g    defaults,uid=emby,rw       0 0

emby says "The path could not be found. Please ensure the path is valid and try again." when i try to add a library in /home/simo/dati_4TB/Film

Edited May 9, 2020 by brofjst

[Luke 42077]

i have some issues with the permission of the filesystem ntfs

mounted by fstab with these parameters:

UUID=myuuid  /home/simo/dati_4TB   ntfs-3g    defaults,uid=emby,rw       0 0

emby says "The path could not be found. Please ensure the path is valid and try again." when i try to add a library in /home/simo/dati_4TB/Film

 

Have you taken a look at this file permissions guide?

https://emby.media/community/index.php?/topic/32218-file-permissions-guide-for-new-linux-users/

[brofjst 0]

yes i've tried this:

UUID=myuuid  /home/simo/dati_4TB   ntfs-3g    rw,uid=emby,gid=emby        0 0

but doesn't work

"If you are mounting the NTFS drive via the fstab, you can set the file permissions by adding rw,uid=username,gid=groupname to the mount options.  For NTFS drives that will never be unplugged from the computer, this is the preferred method to mount the drive."

 

i've also tried

UUID=myuuid  /home/simo/dati_4TB   ntfs-3g    rw,uid=simo,gid=emby        0 0

$ ls -ld Film/
drwxrwxrwx 1 simo emby 45056 May  9 21:22 Film/

 

Edited May 9, 2020 by brofjst

[brofjst 0]

any suggestions? i can't use emby right now

[Luke 42077]

Sorry, how does this prevent you from using Emby? In your first post you said:

 

 

but i can watch them through emby

[brofjst 0]

Yes but now i've moved the movies in a different folder because alucryd said "Placing user files in a `/var/lib` subdirectory is very bad practice," but i can't access at the folder through emby.
Also, as i said in the first post, placing them in /var/lib allows me to watch movies through emby, but i can't access them as normal user through the file browser or other applications.
 

[alucryd 315]

You can't reliably mount that filesystem as the emby user (or group), as I said it's a dynamic user and its uid and gid can change with each restart of the service. You just need to make sure the filesystem is world-readable, and not inside your home directory because dynamic user protects home directories from any tampering by default.

 

If you insist on mounting it in your home directory, you will need to create an additional file for systemd in `/etc/systemd/system/emby-server.service/paths.conf` with the following content:

[Service]
ReadOnlyPaths=/home/simo/dati_4TB

Make it `ReadWritePaths` if you want to save metadata and artwork locally. Then run `systemctl daemon-reload` and restart emby. I believe NTFS is mounted with mode 777 by default so any user should be able to read and write to it, and you can mount as your own user if you so desire.

 

[brofjst 0]

Mounting the filesystem in /mnt solved the issue!

Thank you very much for the support <3

Edited May 16, 2020 by brofjst

[Luke 42077]

Thanks for the feedback !