Roon Core not able to complete backups to CIFS share - failes with coud not write id file

Tinkering
1

Core Machine (Operating system/System info/Roon build number)
FreeNAS w/Docker image (steefdebruijn/docker-roonserver)
Roon Core: version 1.7 (build 528) stable

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Unify Dream Machine (router/switch).
Roon Server host hardwired ethernet
Remote Client: Mac OS X 10.15.3 (wired)

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

KEF LSX wired to Mac

Description Of Issue

Backup functionality not working when trying to use a CIFS share for backup storage. Log file always returns “could not write id file” when trying to perform backup now action.

Here’s relevant excerpt from log file:

03/26 20:15:49 Trace: [broker/backups] doing backup now
03/26 20:15:49 Trace: [broker/backups] computing list of files to back up
03/26 20:15:49 Debug: [broker/backups] preparing sync on FileBrowser.Entry: \\172.16.0.52, memento : \backups\RoonBackups
03/26 20:15:49 Debug: [broker/filebrowser/volumeshare] Use volume, user: broker/backups/startbackup, id: \\172.16.0.52\memento
03/26 20:15:49 Info: [broker/filebrowser/volumeshare] Volume's removable changed: False
03/26 20:15:49 Trace: [backup] preparing backup on dir AttachedDir:/mnt/RoonStorage_1e9dbc46a8dd952082a32c2138428edd75e1fcf3/backups/RoonBackups
03/26 20:15:50 Trace: [backup] migrating backups on dir AttachedDir:/mnt/RoonStorage_1e9dbc46a8dd952082a32c2138428edd75e1fcf3/backups/RoonBackups
03/26 20:15:50 Trace: [backup] merge directories, src: AttachedDir:/mnt/RoonStorage_1e9dbc46a8dd952082a32c2138428edd75e1fcf3/backups/RoonBackups/.tmp-_roon_backup_root_, dst: AttachedDir:/mnt/RoonStorage_1e9dbc46a8dd952082a32c2138428edd75e1fcf3/backups/RoonBackups/tmp-_roon_backup_root_
03/26 20:15:50 Warn: [backup] failed to syncprepare: could not write id file: AttachedDir:/mnt/RoonStorage_1e9dbc46a8dd952082a32c2138428edd75e1fcf3/backups/RoonBackups/5730b408-8736-898c-de9f-2ec081f2d961/_roon_backup_: Result[Status=UnexpectedError, ErrorText=System.IO.IOException: file move failed: -1 errno=EACCES
  at Base.IO.LongPathFile.Move (System.String srcpath, System.String dstpath) [0x00076] in <0b06025a848d463b9cc0ea2fdc978ab1>:0
  at Roon.FileSystem.AttachedFileSystem+<>c__DisplayClass15_0.<PutFile>b__0 () [0x000b1] in <68ab693bd94e41fdbf2626f0db8fffa9>:0
  at System.Threading.Tasks.Task`1[TResult].InnerInvoke () [0x0000f] in <370a0c27f4b74d1a81431037df6d75bf>:0
  at System.Threading.Tasks.Task.Execute () [0x00010] in <370a0c27f4b74d1a81431037df6d75bf>:0
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <370a0c27f4b74d1a81431037df6d75bf>:0
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0003e] in <370a0c27f4b74d1a81431037df6d75bf>:0
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00028] in <370a0c27f4b74d1a81431037df6d75bf>:0
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00008] in <370a0c27f4b74d1a81431037df6d75bf>:0
  at System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult () [0x00000] in <370a0c27f4b74d1a81431037df6d75bf>:0
  at Roon.FileSystem.AttachedFileSystem+<PutFile>d__15.MoveNext () [0x000ee] in <68ab693bd94e41fdbf2626f0db8fffa9>:0 ]
03/26 20:15:50 Warn: [broker/backups] failed sync prepare2 on FileBrowser.Entry: \\172.16.0.52, memento : \backups\RoonBackups: Result[Status=NotAvailable]
03/26 20:15:50 Debug: [broker/backups] on done, auto: False
03/26 20:15:50 Debug: [broker/filebrowser/volumeshare] Use dispose, id: \\172.16.0.52\memento
03/26 20:15:50 Info: [broker/filebrowser/volumeshare] Volume's removable changed: True

I’ve logged onto the Core Host and issue a “mount -l” command. Here’s the relevant info:

mount -l
…
//172.16.0.52/memento on /mnt/RoonStorage_1e9dbc46a8dd952082a32c2138428edd75e1fcf3 type cifs (rw,relatime,vers=2.1,cache=strict,username=XXXXX,domain=WORKGROUP,uid=0,noforceuid,gid=0,noforcegid,addr=172.16.0.52,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

I can readily issue a “touch ‘new_filename’” to the above mount point. However, any attempt to move or delete the touched file results in a permission error.

id
uid=0(root) gid=0(root) groups=0(root)
cd /mnt/RoonStorage_1e9dbc46a8dd952082a32c2138428edd75e1fcf3/backups/RoonBackups
touch 1
ls 1
-rwxr-xr-x 1 root root 0 Mar 26 22:25 1
rm 1
rm: cannot remove ‘1’: Permission denied

Based on these results, I suspect a problem with the way Roon Core is mounting the CIFS share. Any assistance to correct this issue is appreciated.

2

I don’t know why you think that a “Permission denied” error that’s usually issued by the SMB server makes you believe that Roon or the SMB client on it’s host machine is doing something wrong? Have you checked the access rights for the user being used to connect to the SMB server? Does he have sufficient rights on the share?

4

Given my analysis I wanted to get Devs insight on whether the underlying share mount is being done as expected. As is often stated with issues, this previously worked and had been working without issue for some time in my environment. So, the mystery is to determine the delta.

A thorough examination of the moving parts was done prior to reporting the issue.

Areas checked before posting:

  • User ACL on both sides of the data store. ssh and stat are your friend
  • Verify Samba version and configuration
  • Manually verifying file manipulation via CLI on both server and Roon host. Note ‘ls’ command output.
    I have questions about how CIFS shares are mounted and want an informed opinion to verify the mount in this environment. Hence, the output from the mount command. I suspect it is a straight forward configuration related issue.: ‘rwx’ is needed at the directory level. But, where do I make the tweak?

Any insights you may have on the above is appreciated.

5

The problem tracks to the use of using Docker to host Roon image in container. I suspected this when I saw the mount command’s use with user root. I’m still not sure why it worked earlier.

I believe to correct the problem Docker should be run as non-root user. Though I am curious to know if Roon exposes setting setting uid and gid to be used in CIFS mount as this would allow short-circuiting this below Docker image level.

Off to play with Docker image files.

6

Hi @mtjoseph,

We do not perform any testing in VMs/Docker containers for Roon, so I have moved your posts over to the #tinkering section.

Since this behavior only occurs in the Docker container, I would reach out to the Docker image creator to further troubleshoot this behavior.

7

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.