I am attempting to repair permissions issues in my Media folder. I am using Debian Trixie

Posted by orangejuche

My question: I am attempting to repair permissions issues in my Media folder. I am using Debian Trixie SparkBox AI replied: That reply came back blank — try sending it again. If it keeps happening, post in d/sparkbox with your install ID (Settings → Monitoring). What I still need help with: I have attempted to set permissions from the terminal using the command: "sudo setfacl -R -m u:1000:rwX -d -m u:1000:rwX '/mnt/SATA/Media'" However, the permissions are not sticking or still reporting an error when writing to subfolders.

3 replies

Chris wrote:

The setfacl line you ran is exactly the fix SparkBox itself recommends, so the fact that it isn't taking effect points at the drive or the mount rather than at the command on a normal Linux host. There are two common reasons a setfacl ACL does not stick: 1. the filesystem simply doesn't support POSIX ACLs, or 2. the media folder actually lives on a network share whose permissions are decided by the device sharing it. Two read-only checks will tell us which, and neither changes anything: 1. df -T '/mnt/SATA/Media' — the value under Type is the filesystem. ext4, btrfs or xfs all support POSIX ACLs; exfat, vfat (FAT32), ntfs, cifs (SMB) or nfs4 do not — and a network type also means the sharing device owns the permissions. 2. getfacl '/mnt/SATA/Media' — if it lists a line like user:1000:rwx, the ACL was actually stored and the block is something else; if there is no user:1000 entry, setfacl never wrote it. Paste those two outputs here and I'll give you the exact next step. Please don't run setfacl or chown again in the meantime — that would just repeat a step we already know isn't taking, and could spend a long time walking a large library for nothing.

orangejuche wrote:

getfacl '/mnt/SATA/Media' getfacl: Removing leading '/' from absolute path names file: mnt/SATA/Media owner: brucea group: brucea user::rwx user:brucea:rwx group::rwx mask::rwx other::r-x default:user::rwx default:user:brucea:rwx default:group::rwx default:mask::rwx default:other::rwx df -T '/mnt/SATA/Media' Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sda1 ext4 1921725684 646098620 1256075536 34% /mnt/SATA

Chris wrote:

Thanks — these two outputs are exactly what was needed, and the good news is that the setfacl command did land. 1. Your drive is ext4, which fully supports ACLs, so nothing is being rejected at the filesystem level. 2. The getfacl output shows the ACL is actually stored: the user:brucea:rwx line is the u:1000 entry you set (brucea is the name your system shows for UID 1000 — the user SparkBox's apps run as), and the default: lines mean new files and folders created inside should inherit it. So the write error is narrowed to one specific subfolder, not the whole tree. The dashboard's Media Pipeline check doesn't just test the top folder — it also tests every folder one and two levels deep and flags the strip if any of them still isn't writable by UID 1000. One of your subfolders (often one that was created as root, or that predates the ACL run) is that leftover. Next step — read-only, run it in the Linux terminal on the box: sudo sparkbox check-media-perms …and paste the output here. It probes the media folders as the same user the apps use and prints the exact folder path(s) it still can't write, so we'll finally have the name. If it prints all-clear, tell me that too, and we'll pull the dashboard's check to see which folder it disagrees on. Stopping point: leave setfacl and chown alone for now — the recursive pass already covered everything else, and re-running it won't help until we know which folder is blocking.