Please help w Permission Issues and Backup Failure

[Ahole 17]

I have Emby server running as a Docker on Ubuntu server (using Portainer stacks to create):
It is created with the following compose:

---
services:
  emby:
    image: emby/embyserver:beta
    container_name: emby
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
    network_mode: bridge
    volumes:
      - /DATA/AppData/EmbyConfig:/config
      - /mnt/192.168.1.144/CromBackup:/crombackup
      - /mnt/data:/data
      - /mnt/data/media/movies:/movies
      - /mnt/data/media/tv:/tvshows
      - /mnt/channels-dvr:/channels-dvr
      - /mnt/data/NewEmmBeeBackup:/backup

    ports:
      - 8096:8096
      - 8922:8920 #optional
    devices:
      - /dev/dri:/dev/dri #optional
    restart: unless-stopped

 

I can access media in Emby.
I have rw access when logged into my server machine and accessing the /mnt share that the Emby Backup would be writtent to (NewEmmBeeBackup folder)

I was able to write or create a Test2 folder from that log 

But for some resason Emby cannot complete or write a backup to that shared folder on my NAS --- and it seems to be riddled with some other permission errors as well.

Can a Linus saavy person please help

embyserver (2).txt

[Ahole 17]

I'm not sure if it helps but I am seeing that IF I experiment and set backup to a local folder (on the same machine as the docker is on) - the backup is succesful and Emby creates files that list "bin" as the owner.
I notice that the other files that I have had created by docker containers are created as "root"
Do I have my portainer / stack / docker setup wrong or something?

 

[Ahole 17]

@Luke
Now I am reaslly confused -- I can write to the folder from the Emby Container console in Portainer !!

So why would Emby being giving a permission denied for backing up to that folder ????

[Ahole 17]

Are you guys trying to make it so that Emby can't be backed up to a network drive?

 

[Q-Droid 989]

 

[Ahole 17]

Any ideas would be appreciated.  I’ve been communicating with guys that know Linux way better than me

 can’t figure it out

[Ahole 17]

Nobody has any experience with permission issues running docker ??   Seems to mainly be the backup function

Have tried almost everything.   Do most of you run docker as root (which seems to be the default for how docker compose works in portainer)?
 

[Q-Droid 989]

Did you even bother to read the thread I posted above?

 

[Ahole 17]

27 minutes ago, Q-Droid said:

Did you even bother to read the thread I posted above?

 

I did read it - thank you
I have been in continued contact with people who know far more than I do about Linux - nobody can seem to make since of not being able to write the backup file (regardless of the type of file) to a folder that otherwise has access for RW

I just went into my docker container console (for emby) and was able to wriite files from the Emby docker to the mounted folder chosen for backups

I am just trying to get a developer to look at the problem as it seems to be "Emby" related (according to the guys that know Linux) - or at least respond to the thread 

[Q-Droid 989]

How are you mounting the shares on the Emby server host?

 

 

[Ahole 17]

28 minutes ago, Q-Droid said:

How are you mounting the shares on the Emby server host?

 

 

sudo mount -t cifs //192.168.1.144/data /mnt/data -o username=myuseradmin,password=xxxxxxx

The folders that are being written to are 777 and fully writable from the docker console in portainer

[Q-Droid 989]

 

The linked thread has info you and your friends could have followed, the nobrl mount option specifically for the backup related problems. Other permissions still need to be done right.

So as a test try:

sudo mount -t cifs //192.168.1.144/data /mnt/data -o nobrl,username=myuseradmin,password=xxxxxxx

If that works then consider using /etc/fstab to mount the shares automatically on boot instead of manually or with a script. Also, instead of using un/pw in the mount command you can create a file to use for credentials.

Like /etc/ahole.cifs with:
username=value
password=value

Then in the fstab add each share to mount:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl 0 0

You can try to force permissions on files and directories created on the share from the client (Ubuntu Emby server) side:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,file_mode=0664,dir_mode=0775 0 0

And you can try to force ownership of the mount, might prevent access by others on the client side:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,uid=1000,gid=1000 0 0

Ownership and permissions are dependent on how you plan to access and manage the media files and directories. If you have multi-user access in mind then ownership and permissions have to be aligned to allow different user access. 

[Ahole 17]

1 hour ago, Q-Droid said:

 

The linked thread has info you and your friends could have followed, the nobrl mount option specifically for the backup related problems. Other permissions still need to be done right.

So as a test try:

sudo mount -t cifs //192.168.1.144/data /mnt/data -o nobrl,username=myuseradmin,password=xxxxxxx

If that works then consider using /etc/fstab to mount the shares automatically on boot instead of manually or with a script. Also, instead of using un/pw in the mount command you can create a file to use for credentials.

Like /etc/ahole.cifs with:
username=value
password=value

Then in the fstab add each share to mount:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl 0 0

You can try to force permissions on files and directories created on the share from the client (Ubuntu Emby server) side:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,file_mode=0664,dir_mode=0775 0 0

And you can try to force ownership of the mount, might prevent access by others on the client side:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,uid=1000,gid=1000 0 0

Ownership and permissions are dependent on how you plan to access and manage the media files and directories. If you have multi-user access in mind then ownership and permissions have to be aligned to allow different user access. 

I'll try it -- thank you !!

 

[Ahole 17]

1 hour ago, Q-Droid said:

 

The linked thread has info you and your friends could have followed, the nobrl mount option specifically for the backup related problems. Other permissions still need to be done right.

So as a test try:

sudo mount -t cifs //192.168.1.144/data /mnt/data -o nobrl,username=myuseradmin,password=xxxxxxx

If that works then consider using /etc/fstab to mount the shares automatically on boot instead of manually or with a script. Also, instead of using un/pw in the mount command you can create a file to use for credentials.

Like /etc/ahole.cifs with:
username=value
password=value

Then in the fstab add each share to mount:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl 0 0

You can try to force permissions on files and directories created on the share from the client (Ubuntu Emby server) side:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,file_mode=0664,dir_mode=0775 0 0

And you can try to force ownership of the mount, might prevent access by others on the client side:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,uid=1000,gid=1000 0 0

Ownership and permissions are dependent on how you plan to access and manage the media files and directories. If you have multi-user access in mind then ownership and permissions have to be aligned to allow different user access. 

I'll try it -- thank you 

 

2 hours ago, Q-Droid said:

 

The linked thread has info you and your friends could have followed, the nobrl mount option specifically for the backup related problems. Other permissions still need to be done right.

So as a test try:

sudo mount -t cifs //192.168.1.144/data /mnt/data -o nobrl,username=myuseradmin,password=xxxxxxx

If that works then consider using /etc/fstab to mount the shares automatically on boot instead of manually or with a script. Also, instead of using un/pw in the mount command you can create a file to use for credentials.

Like /etc/ahole.cifs with:
username=value
password=value

Then in the fstab add each share to mount:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl 0 0

You can try to force permissions on files and directories created on the share from the client (Ubuntu Emby server) side:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,file_mode=0664,dir_mode=0775 0 0

And you can try to force ownership of the mount, might prevent access by others on the client side:
//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,uid=1000,gid=1000 0 0

Ownership and permissions are dependent on how you plan to access and manage the media files and directories. If you have multi-user access in mind then ownership and permissions have to be aligned to allow different user access. 

I tried it (thank you for the advice for changing my fstab - I already had the lines in there but had not done the credentials file)

It still did not work 
Not sure if I needed to restart anything to make the settings stick or do anything with the Emby server -- but after adding the noblr to the mount statement it still - permission denied for the backup

 

Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3

Operating system: Linux version 6.8.0-52-generic (buildd@lcy02-amd64-046) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubunt

OS/Process: x64/x64

Framework: .NET 8.0.11

Runtime: system/System.Private.CoreLib.dll

Processor count: 22

Data path: /config

Application path: /system

System.UnauthorizedAccessException: System.UnauthorizedAccessException: Access to the path '/data/NewEmmbeeBackup/embyserver-backup-full/config' is denied.

---> System.IO.IOException: Permission denied

--- End of inner exception stack trace ---

at System.IO.FileSystem.CreateDirectory(String fullPath, UnixFileMode unixCreateMode)

at System.IO.Directory.CreateDirectory(String path)

at Emby.Server.Implementations.IO.ManagedFileSystem.CreateDirectory(String path)

at MBBackup.Sync.Sync.SyncDirectories(String source, String destination, Boolean recursive, String[] ignoreFileNames, String[] ignoreSubfolderNames, String[] limitToFileExtensions, Boolean deleteRightOnlyFiles, Boolean throwExceptions, CancellationToken cancellationToken)

at MBBackup.Sync.Sync.SyncDirectories(String source, String destination, Boolean deleteRightOnlyFiles, CancellationToken cancellationToken)

at MBBackup.Sync.Sync.SyncDirectories(String source, String destination, CancellationToken cancellationToken)

at MBBackup.ServerEntryPoint.ExecuteBackup(PluginConfiguration configuration, CancellationToken cancellationToken, IProgress`1 progress)

at Emby.Server.Implementations.ScheduledTasks.ScheduledTaskWorker.ExecuteInternal(TaskOptions options)

Source: System.Private.CoreLib

TargetSite: Void CreateDirectory(System.String, System.IO.UnixFileMode)

InnerException: System.IO.IOException: Permission denied

Source:

TargetSite:

 

2025-02-01 17:41:12.353 Info TaskManager: Emby Server Backup Failed after 0 minute(s) and 0 seconds

[Ahole 17]

Also got this error when I tried to force the permissions when things didn't initailly work -- see my commands and the result:

 

ahole4sure@rosegatemedia:/mnt/data$ sudo mount -t cifs //192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,uid=1000,gid=1000 0 0

mount: bad usage

Try 'mount --help' for more information.

[Q-Droid 989]

You have to use -o for the options from a command line, like your original one. The -o argument is not used in the fstab.

If you make changes to the fstab the easiest thing to do is reboot to be sure any modifications take effect. Then you can run mount command by itself to show what's mounted and what options were used.

 

[Ahole 17]

2 hours ago, Q-Droid said:

You have to use -o for the options from a command line, like your original one. The -o argument is not used in the fstab.

If you make changes to the fstab the easiest thing to do is reboot to be sure any modifications take effect. Then you can run mount command by itself to show what's mounted and what options were used.

 

Well hallaleuha - OMG - probably 10 hrs of learning Linux the hard way and ESPECIALLY WITH YOUR HELP!!!!!

I had to use the last method or idea before it finally worked!

//192.168.1.144/data /mnt/data cifs credentials=/etc/ahole.cifs,rw,nobrl,uid=1000,gid=1000 0 0

This lead to what we expected - but most importantly Emby like it.  I guess I'll have to wait and see if I have any side effects with other programs.
 

drwxr-xr-x 2 ahole4sure ahole4sure 0 Feb  1 21:37  .

drwxr-xr-x 2 ahole4sure ahole4sure 0 Jan 31 09:34  ..

drwxr-xr-x 2 ahole4sure ahole4sure 0 Feb  1 21:38  embyserver-backup-full

drwxr-xr-x 2 ahole4sure ahole4sure 0 Feb  1 21:37 'Emby Server Databases - 2025-02-01 21.37.36'

-rwxr-xr-x 1 ahole4sure ahole4sure 0 Feb  1 13:09  example.txt

drwxr-xr-x 2 ahole4sure ahole4sure 0 Jan 31 11:19  Test

drwxr-xr-x 2 ahole4sure ahole4sure 0 Jan 31 13:23  test2

drwxr-xr-x 2 ahole4sure ahole4sure 0 Jan 31 13:55  test3

drwxr-xr-x 2 ahole4sure ahole4sure 0 Jan 31 17:38  test4

ahole4sure@rosegatemedia:/mnt/data/NewEmmbeeBackup$ 

maybe this should be pinned in the linux forum @Luke

Thanks again @Q-Droid