Having issues with renaming folders and files. updated to latest ver some logs from lidarr 2026-09-29 04:19:00.9|Debug|DiskProvider|Setting permissions: 755 on /data/Music/The Notorious B.I.G/Life After Death (1997)/CD 02/The Notorious B.I.G. - Life After Death - 03 - Another.flac 2026-09-29 04:19:00.9|Warn|MediaFileAttributeService|Unable to apply permissions to: /data/Music/The Notorious B.I.G/Life After Death (1997)/CD 02/The Notorious B.I.G. - Life After Death - 03 - Another.flac [v3.1.0.4875] NzbDrone.Mono.Disk.LinuxPermissionsException: Error setting permissions: EPERM at NzbDrone.Mono.Disk.DiskProvider.SetPermissions(String path, String mask, String group, FilePermissions permissions) in ./NzbDrone.Mono/Disk/DiskProvider.cs:line 121 at NzbDrone.Mono.Disk.DiskProvider.SetPermissions(String path, String mask, String group) in ./NzbDrone.Mono/Disk/DiskProvider.cs:line 96 at NzbDrone.Core.MediaFiles.MediaFileAttributeService.SetMonoPermissions(String path) in ./NzbDrone.Core/MediaFiles/MediaFileAttributeService.cs:line 87 2026-09-29 04:19:00.9|Debug|AudioTag|Starting tag read for /data/Music/The Notorious B.I.G/Life After Death (1997)/CD 02/The Notorious B.I.G. - Life After Death - 03 - Another.flac 2026-09-29 04:19:01.0|Debug|AudioTag|Audio Properties: Flac Audio, Bitrate: 1009, Sample Size: 16, SampleRate: 44100, Channels: 2 2026-09-29 04:19:01.0|Debug|QualityParser|Trying to parse quality for '/data/Music/The Notorious B.I.G/Life After Death (1997)/CD 02/The Notorious B.I.G. - Life After Death - 03 - Another.flac' 2026-09-29 04:19:01.0|Debug|AudioTag|Quality parsed: FLAC v1, Source: TagLib 2026-09-29 04:19:01.0|Debug|AudioTagService|Scrubbing tags for [0] /data/Music/The Notorious B.I.G/Life After Death (1997)/CD 02/The Notorious B.I.G. - Life After Death - 03 - Another.flac 2026-09-29 04:19:01.0|Debug|AudioTagService|Writing tags for [0] /data/Music/The Notorious B.I.G/Life After Death (1997)/CD 02/The Notorious B.I.G. - Life After Death - 03 - Another.flac 2026-09-29 04:19:01.0|Debug|AudioTag|Starting tag write for /data/Music/The Notorious B.I.G/Life After Death (1997)/CD 02/The Notorious B.I.G. - Life After Death - 03 - Another.flac 2026-09-29 04:19:47.2|Warn|LidarrErrorPipeline|System.UnauthorizedAccessException: Root folder path '/data/Music' is not writable by user 'abc' [v3.1.0.4875] System.UnauthorizedAccessException: Root folder path '/data/Music' is not writable by user 'abc' at NzbDrone.Core.RootFolders.RootFolderService.VerifyRootFolder(RootFolder rootFolder) in ./NzbDrone.Core/RootFolders/RootFolderService.cs:line 98 at NzbDrone.Core.RootFolders.RootFolderService.Update(RootFolder rootFolder) in ./NzbDrone.Core/RootFolders/RootFolderService.cs:line 123 at Lidarr.Api.V1.RootFolders.RootFolderController.UpdateRootFolder(RootFolderResource rootFolderResource) in ./Lidarr.Api.V1/RootFolders/RootFolderController.cs:line 86 at lambdamethod251(Closure, Object, Object[]) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync() at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsyncgAwaited|200(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsyncgAwaited|170(ResourceInvoker invoker, Task task, IDisposable scope) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsyncgAwaited|170(ResourceInvoker invoker, Task task, IDisposable scope) at Lidarr.Http.Middleware.BufferingMiddleware.InvokeAsync(HttpContext context) in ./Lidarr.Http/Middleware/BufferingMiddleware.cs:line 27 at Lidarr.Http.Middleware.IfModifiedMiddleware.InvokeAsync(HttpContext context) in ./Lidarr.Http/Middleware/IfModifiedMiddleware.cs:line 40 at Lidarr.Http.Middleware.CacheHeaderMiddleware.InvokeAsync(HttpContext context) in ./Lidarr.Http/Middleware/CacheHeaderMiddleware.cs:line 32 at Lidarr.Http.Middleware.StartingUpMiddleware.InvokeAsync(HttpContext context) in ./Lidarr.Http/Middleware/StartingUpMiddleware.cs:line 37 at Lidarr.Http.Middleware.UrlBaseMiddleware.InvokeAsync(HttpContext context) in ./Lidarr.Http/Middleware/UrlBaseMiddleware.cs:line 28 at Lidarr.Http.Middleware.VersionMiddleware.InvokeAsync(HttpContext context) in ./Lidarr.Http/Middleware/VersionMiddleware.cs:line 28 at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.InvokeCore(HttpContext context) at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddlewareImpl.<InvokegAwaited|100(ExceptionHandlerMiddlewareImpl middleware, HttpContext context, Task task)
19 replies
Chris wrote:
Those errors show Lidarr cannot write to its mounted music folder; they don't yet tell us why the host or share is denying that write. On the SparkBox server itself (not inside a container), please run sudo sparkbox doctor and share just your SparkBox version, whether this is Linux or a NAS (and which one), and the media-folder writability result or warning. Please omit the full path and any library details, and don't change ownership yet.
wildwill wrote:
SparkBox v1.6.810 windows 11 [Media Storage] [OK] MEDIAROOT=/mnt/ [OK] MEDIAROOT is writable by your apps (user id 1000) [OK] Your apps (user id 1000) can read your media library [INFO] Free space at MEDIAROOT: 11554GB
Chris wrote:
Thanks—that confirms SparkBox's media check can write to the mounted folder, but Lidarr's own errors still show it cannot set file permissions and does not consider its root folder writable. Since this is Windows 11, the next useful detail is whether SparkBox uses Docker Desktop or Docker Engine installed inside WSL. Which one are you using? Please don't change ownership or permissions yet; this result alone doesn't tell us which layer is denying Lidarr.
wildwill wrote:
i believe its docker desktop since i am not on linux
wildwill wrote:
how to check to be certain?
Chris wrote:
Easy check, and good news: if you installed with SparkBox's Windows installer, it's not Docker Desktop. SparkBox makes its own Linux machine called SparkBox with Docker inside it and never uses Docker Desktop. To confirm, open PowerShell and run wsl -l -v. A line starting with SparkBox (state Running, version 2) is the one your apps live in. If Docker Desktop is also installed it shows up as docker-desktop, and SparkBox doesn't touch it. What's actually going on with Lidarr: that doctor line only tests the very top of your media folder. Lidarr's error is about the Music folder underneath it. That folder, and what's in it, belongs to a different Linux account than your apps (user id 1000), so Lidarr can't rename inside it. That's also why it can't change file permissions. One common way this happens is copying music in from Windows through the \\wsl$ path, or with sudo, because those copies are owned by root. One next step, in the same place you ran doctor: sudo sparkbox check-media-perms It tests Music and every artist and album folder from inside Lidarr itself. If the only problem is the top Music folder, it gives it back to your apps on its own. If it lists folders it couldn't fix and suggests a command, stop there and paste just those last lines here with the folder names swapped for X. Please don't run chown or chmod on the library before that. Separately: the "Error setting permissions: EPERM" lines come from Lidarr's optional Set Permissions setting (Settings Media Management, advanced settings shown). SparkBox doesn't need it, so you can switch it off. And the next SparkBox update makes doctor name any library folder your apps can't write into, so it won't show a plain OK for this again.
wildwill wrote:
Your apps can read your existing media AND write to the download folders (PUID=1000).
Chris wrote:
You're right: that doctor result confirms your apps can read the locations it checks and write to the download folders. I'm sorry—I wrongly inferred that your existing library was owned by a different account, and I shouldn't have stated that your Windows setup proves which Docker engine is in use. The doctor result doesn't verify Lidarr's ability to rename every existing Music folder; its EPERM permissions warning and its root-folder-not-writable message also don't, by themselves, establish the cause. One check: does the rename fail only for items already in your library, or also when Lidarr moves a newly downloaded item into the library? Please don't change ownership or permissions. I've corrected what I know about this case so I won't repeat that unsupported diagnosis.
wildwill wrote:
it fails for items that were in my music collection
Chris wrote:
Sorry—I pointed you to check-media-perms as though its result could settle this. Its green check can miss the deeper artist/album folders Lidarr uses, so it does not prove Lidarr can write to your existing collection. The log confirms Lidarr is being denied a write, but we have not established which storage layer is doing it. One detail that will narrow this down: is that collection stored on a Windows drive, or inside the SparkBox Linux filesystem? Please don't change permissions or ownership. I've corrected what I know so this unsupported all-clear isn't repeated.
wildwill wrote:
K:\Media\Music that is the folder in question thats where the music files that will not rename not downloads
wildwill wrote:
2026-09-29T10:17:38.299955766Z [Info] IdentificationService: Identifying album 16/1667 2026-09-29T10:17:57.445690170Z [Warn] FingerprintingService: fpcalc timed out. 2026-09-29T10:18:04.482444480Z [Info] IdentificationService: Identifying album 17/1667 2026-09-29T10:18:27.246378311Z [Warn] FingerprintingService: fpcalc timed out. 2026-09-29T10:18:45.918559061Z [Warn] FingerprintingService: fpcalc timed out. 2026-09-29T10:19:01.062131152Z [Info] IdentificationService: Identifying album 18/1667 2026-09-29T10:19:11.071281082Z [Warn] FingerprintingService: fpcalc timed out. logs from lidarr dont know if they are relevant to the issue at hand
Chris wrote:
Those fpcalc timed out messages look like separate library-scan warnings; they don't explain Lidarr's write-permission error. Since the existing collection is on a Windows drive, we still need to check whether SparkBox's Docker can see that drive mount. From the SparkBox WSL terminal, run sudo sparkbox doctor and share only any warning about the media drive being mounted for the terminal but not Docker (please replace any path with [path]). Don't change permissions or ownership yet.
wildwill wrote:
[OK] MEDIAROOT=/path [OK] MEDIAROOT is writable by your apps (user id 1000) [OK] Your apps (user id 1000) can read your media library [INFO] Free space at MEDIAROOT: 11553GB
Chris wrote:
I'm sorry—I sent you to check whether Docker could see the drive; this result shows it can see and write to the tested media location. It does not test write access to the specific folder Lidarr reports, and the EPERM message alone doesn't tell us why that folder is refusing the operation. One check: can you already rename an ordinary file inside that folder using Windows Explorer? Please don't rename anything just to test. I've corrected what I know about this case so I won't repeat the unsupported mount diagnosis.
wildwill wrote:
yes i am able to rename using file explorer
Chris wrote:
I'm sorry for the earlier unsupported ownership diagnosis: SparkBox 1.6.810's doctor checked only the top-level media folder, so it could miss a library folder Lidarr couldn't write to; SparkBox 1.6.814 adds checks for those library folders. Being able to rename in Windows Explorer confirms your Windows account can write there, but doesn't test Lidarr's access. Please update SparkBox to 1.6.814, then run its doctor and tell me whether it flags a library folder; don't change permissions yet. I've corrected what I know about this case so the unsupported ownership diagnosis isn't repeated.
wildwill wrote:
SparkBox Core Current version: 1.6.813 (up to date)
Chris wrote:
Thanks for checking. I can see why this is confusing: 1.6.814 adds the doctor check for app write access inside existing library folders, but your dashboard still reports 1.6.813 as up to date. I can't verify that 1.6.814 is available to your box yet, so please don't force an upgrade or change permissions. Please let me know when the updater offers 1.6.814; then we can use that doctor result to guide the next step. We'll keep this open in the meantime.