Rock - Guest privileges with New USB Driver

Roon Core Machine

Roon Core - Nuc running Linux Ver 1 (build 254)
Roon Rock 2.0 Build 1148 ethernet
Description of Issue

For the last three year I have used Carbon Copy Cloner (CCC) a backup application to clone my Music Library from my Mac Pro to my Roon Rock server. My Library is on USB attached disk drives.

The app logs in as “guest” then copies and deletes files as necessary to ensure the music library is an exact copy of my main library. This app runs nightly even though I have nothing to add or delete.

As part of its task CCC copies a test file to the USB volume to determine what flags are supported. After CCC has completed these file flag tests, it strips all flags from the test file and then deletes the file. In this case it looks like the NAS volume isn’t allowing CCC to remove the flag that CCC added to the file.

The test file is a TXT file which is locked. The file cannot be unlocked by CCC or by logging in to Rock as a “Guest” This is new with the recent update.

After the Rock Upgrade to Ver 1 (Build 254) with “Updated exFAT and NTFS driver” the backup software CCC was not able to delete the file by unlocking it. Only Guest access is available for the backup program or my self.

In Summary:
The new USB driver and/or settings in Rock kernel is not allowing a Guest user to remove the “file is locked” flag from a file. Awkwardly, though, it allows that Guest user to set the “file is locked” flag.

From my standpoint Guest privileges, should allow you to either set Lock/unlock or not. But to let lock but not unlock is a bug.

Since the recent update “improved support for USB storage devices formatted with the exFAT” I wonder if this is the cause of the issue and how I can fix the problem.


looking into this…

1 Like

Has there been any progress here?

No, no progress.

Can you tell me how you know about exactly what CCC is doing? I want to poke a bit further into what locking mechanism it’s using.

I am able to reproduce a weird state where I can lock but not unlock a file (using MacOS’s Get Info → Lock checkbox)

that seems to change file perms from 644 → 444, but won’t let me go back to 644.

if I manually change the file to 744, it goes to 544, but has no issue going back to 744.

I’m testing on //ROCK/Data, which is ext4 – not exFat. I didn’t change smbd config in this release, so im really confused by what’s going on if it’s the same “Lock” as Get Info → Lock.

I contacted CCC support first. They supplied me with the early troubleshooting information. There support contact is

There message to me was:

CCC creates that file on the destination at the beginning of the task so it can determine which file flags the destination volume supports (e.g. “file is locked”, “file is hidden”). This isn’t my preferred method for making that assessment – ideally I’d query the volume for this information, but there isn’t a way to do that. The only way we can determine which file flags are supported by a volume is to create a test file and then try to set the flags. If we get “operation not supported” for a particular flag, then we don’t ever attempt to set that flag on any files (this avoids a barrage of errors in cases where the source filesystem supports more flags than the destination filesystem).

Normally, however, if a volume supports setting a flag then it also supports unsetting that flag. After CCC has completed these fileflag tests, it strips all flags from the test file and then deletes the file. In this case it looks like the NAS volume isn’t allowing CCC to remove the flag that CCC added to the file. I think I’ve seen this happen once or twice in the past, but I don’t think I was ever able to get any insight into what setting on the NAS was causing it. It seems like it would be some kind of access control that is applied to the NAS shared volume.

I only have Guest access so no admin privileges.

This may be the underlying issue, perhaps the NAS isn’t going to allow a Guest user to remove the “file is locked” flag from a file. Awkwardly, though, it allows that Guest user to set the “file is locked” flag. Is there any way to mount that NAS storage with a non-guest account on the NAS device? If you can mount the NAS volume with privileges, drag the “HD Library” folder from the mounted NAS volume in the Finder onto CCC’s Destination selector to update the task spec, then try running the task again.

You should be able to contact their support email. They are responsive and got back to me in one business day.

I hope that helps. My daily backup/clone to Roon finishes everyday with errors because of this issue.


Bombich, who are developers of CCC sent me addition information to assist you.

I can’t post to that forum without setting up an account, but here’s the gist of what CCC does (and you’re welcome to post this publicly):

NSString *path = [destinationPath stringByAppendingPathComponent:@"CCC_Test_File.txt"];
unlink(path.UTF8String); // blind attempt to delete an existing file
int fileDescriptor = open(path.UTF8String, O_CREAT | O_RDWR, 0666);

int unsupportedFlags = 0;
// Call fchflags(fileDescriptor, x) for each of the following flags "x":
// If the fchflags call fails with ENOTSUP, add the flag to unsupportedFlags

// Clean up
fchflags(fileDescriptor, 0) // strip all file flags
unlink(path.UTF8String) // Delete the test file

Now that I’m thinking about it, you should be able to do all of this in the Terminal, and maybe that’s the simplest way to present this to Roon:

cd /Volumes/Data
touch test_file
chflags nodump test_file
chflags uchg test_file
chflags uappend test_file
chflags opaque test_file
chflags hidden test_file
sudo chflags sappend test_file
sudo chflags 0 test_file
rm test_file

The only flag we can’t test this way is the “tracked” flag, but I doubt that one is problematic (it’s probably just not supported on the SMB filesystem). But now I wonder if that sappend flag could be the problem here. If you’re able to reproduce the issue with the steps above (i.e. if test_file can’t be deleted), then I’d try the following:

cd /Volumes/Data
touch test_file_2
chflags nodump test_file_2
chflags uchg test_file_2
chflags uappend test_file_2
chflags opaque test_file_2
chflags hidden test_file_2
chflags 0 test_file_2
rm test_file_2

If that fixes the issue, I could drop the test for the sappend flag.


I hope this is of assistance to your in arriving at a solution.


Has this information been helpful. Are we closer to finding a solution.

Please provide a status. If you need additional information I will attempt to get it for you.


Is there any more information concerning the cause of this issue?


I still have this issue even after the last update. Is there anyone looking into this problem?

It has been over three weeks with no progress.


Has any progress been made on this issue? I am disappointed with the level of support which is being provided.


No progress. I’m able to reproduce and a cursory examination shows no that smb settings or software has changed. It seems that something different is going on in the Linux 5 system. I can reproduce this on ext4, so it has nothing to do with exFAT or NTFS.

I’ll keep at it, but you may need to replace ROCK with Ubuntu if you need this fixed soon.

I have ran the tests which were proposed before by Bombich. The “chflags uchg” command is locking the file but the “chflsgs 0” command is not able to unlock the file. I have confirmed that the “uchg” flag is being set. This is a bug or a configuration issue around the guest client that we are given for accessing the Data directory.

I have difficulty believing this is a bug given Linux’s user base. Someone should have seen this behaviour before. It has only occurred since the recent Roon’s recent OS update.

Are we missing something fundamentally?


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