Hey guys, I’ve been running the linuxserver/lidarr container on Unraid for a long time with no problems. Over the last week or two, any new artist folders that Lidarr creates under /media/data/music/artists end up with incorrect permissions. Because of this, I can’t write to, edit, or delete those folders/files via SMB — I get permission denied errors. Just to list the issues Only affects folders created by Lidarr. Older artist folders work fine Sonarr/Radarr using similar paths are unaffected No Unraid, SMB, or Docker permission changes were made the issue appeared suddenly, so I’m wondering if a recent Lidarr/container update changed something (UMASK-related?) For now I have to manually fix permissions after folders are created, which will obviously allow me to edit/delete etc etc. Any ideas what could be causing this or what I should check? I'm kind of at my wits end trying stuff so thought I'd reach out today.

I am starting to think its an SMB setting? No other directory is affected, it's just folders created by Lidarr. If i run new safe permissions I can then obviously edit/delete those files from Windows file explorer. If you guys need logs please let me know which you need and I will upload them.

Are all 'arrs using the same downloader?

1 hour ago, trurl said:

Are all 'arrs using the same downloader?

Yes downloaders are the same across all the AARs. Deluge and SABnzb are the only two clients I use.

Post docker run for lidarr

8 minutes ago, trurl said:

Post docker run for lidarr

Sure thing here you go.

^{Command execution}

^{docker run}

^-d

^{--name='lidarr'}

^{--net='darknight'}

^{--ip='172.18.0.7'}

^{--pids-limit 2048}

^{-e TZ="Australia/Brisbane"}

^{-e HOST_OS="Unraid"}

^{-e HOST_HOSTNAME="AresLab"}

^{-e HOST_CONTAINERNAME="lidarr"}

^{-e 'PUID'='99'}

^{-e 'PGID'='100'}

^{-e 'UMASK'='022'}

^{-l net.unraid.docker.managed=dockerman}

^{-l net.unraid.docker.webui='http://[IP]:[PORT:8686]/system/status'}

^{-l net.unraid.docker.icon=''}

^{-p '8686:8686/tcp'}

^{-v '/mnt/user/data/':'/data':'rw'}

^{-v '/mnt/user/appdata/lidarr':'/config':'rw' 'lscr.io/linuxserver/lidarr:nightly'}

^{9633f52520ef551fae03c47ca4c7303a8276b418659fa7600031b62936b635db}

^{The command finished successfully!}

UMASK looks OK there, I guess you could loosen it up a bit with 002 or even 000 and see if that helps

1 minute ago, trurl said:

UMASK looks OK there, I guess you could loosen it up a bit with 002 or even 000 and see if that helps

I did try this option, unfortunately it still gave me 'You do not have permission to perform this action' when accessing it via SMB. I can obviously edit/delete the folder and it's contents via Krusader/Terminal. I am just not able to via Windows. All of my other shares are fine. It's just whatever Lidarr creates I no longer have write permissions until I run New Permissions. Then obviously once a new folder/files are created by Lidarr I run into the same problem. It only just started maybe a week or so ago. Only noticed it by accident as I went to edit some music files manually which I do sometimes.

Here are my SMB settings in unraid. Nothing I do allows write permissions on newly created folders from Lidarr.

Here are my diagnostic logs. areslab-diagnostics-20260107-2141.zip

Open up a Terminal session for the WEBGUI and run the following commands:

ls -al /mnt/user/media/data/music

ls -al /mnt/user/media/data/music/artists

Then capture screenshots of the output.

Quick observation: you should have 777 permissions directories/folders and 666 permissions on files. If you want to know why see here:

https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561580

18 hours ago, z0ki said:

18 hours ago, trurl said:

UMASK looks OK there, I guess you could loosen it up a bit with 002 or even 000 and see if that helps

I did try this option, unfortunately it still gave me 'You do not have permission to perform this action' when accessing it via SMB.

Understand that changing the UMASK will only change things for directory/files written after the change! Anything written before the change will not be affected. To correct those items you can run the "New Permissions" tool found under the TOOLS tab. Run it only on the Share that has the problem. (Read the warnings before running!!!) Note that it can take considerable time to complete depending on the number of items in the Share.

My earlier suggestion was to allow diagnose of the problem to make sure that the problem is fixed permanently.

10 hours ago, Frank1940 said:

Open up a Terminal session for the WEBGUI and run the following commands:

ls -al /mnt/user/media/data/music

ls -al /mnt/user/media/data/music/artists

Then capture screenshots of the output.

Quick observation: you should have 777 permissions directories/folders and 666 permissions on files. If you want to know why see here:

https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561580

Ok i ran this. As i ran new permissions everything was shown as drwxrwxrwx which is correct. I then added a new artist via Lidarr re-ran the command for the artist directory and that newly created folder shows drwxr-xr-x

Just noticed some I did recently have this same problem despite my UMASK. I don't run Lidarr very often. Maybe something with the current version.

3 minutes ago, trurl said:

Just noticed some I did recently have this same problem despite my UMASK. I don't run Lidarr very often. Maybe something with the current version.

Interesting! I might try and go back to an older linuxserver lidarr version and see if this fixes it.

@z0ki , make sure that you had the UMASK set to 000 when these new directories were being created.

11 minutes ago, Frank1940 said:

@z0ki , make sure that you had the UMASK set to 000 when these new directories were being created.

Would I add this as a variable in the container template?

You already had it in your docker run you posted. And you said you had changed it, or at least that's what I thought you meant.

I just tried it again and changed my UMASK to 000, and it works correctly.

38 minutes ago, trurl said:

I just tried it again and changed my UMASK to 000, and it works correctly.

Ha. Yeah i just did it again saved changes got a new artist created via Lidarr and permissions are ok now. I never needed to change this setting in the past. I wonder why it's required now all of a sudden?

1 hour ago, z0ki said:

I wonder why it's required now all of a sudden?

I believe the current Linux security recommendation for permissions is now 755 (directories) and 644(files). I would suspect that these recommendations are now finding their way into the various Linux distributions and are showing up when the Docker containers are updated with the newer distributions.

One more question that i've noticed. For deleted Lidarr folders they get deleted via the recycling bin option to another directory which are kept there for 7 days. These have no write permissions and I am unable to delete them manually. The folders Lidarr are creating are functioning as normal, but the ones being deleted to another path have no permissions. I do not see anything in Lidarr specifically regarding read/write permissions for deleted folders.