Read-only file system when running backup

[Hsgnd 2]

I have a hard drive that is shared with a Windows 11 install.

I have this hard drive on my fstab file

# /dev/sda2
UUID=D6C45D9BC45D7F25	/mnt/stuff	ntfs3 	rw,nofail,uid=doug,gid=stuffaccess	0 2

I created the group "stuffaccess" and included my user and emby as well

 

The error occurs when my server tries to run the backup scheduled task which logs the error

Read-only file system : '/mnt/stuff/Backup/Emby/embyserver-backup-full/data/library.db' at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode) at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize) at System.IO.FileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite) at Emby.Server.Implementations.ApplicationHost.BackupDatabases(String destinationFolder) at MBBackup.ServerEntryPoint.ExecuteBackup(PluginConfiguration configuration, CancellationToken cancellationToken, IProgress`1 progress) at Emby.Server.Implementations.ScheduledTasks.ScheduledTaskWorker.ExecuteInternal(TaskOptions options)

But when I run ll /mnt/stuff/Backup/Emby the output is

~ » ll /mnt/stuff/Backup/Emby
total 8.0K
drwxrwxr-x 1 doug stuffaccess 4.0K Sep  9 17:14 'Emby Server Databases - 2024-09-09 17.14.49'
drwxrwxr-x 1 doug stuffaccess 4.0K Sep  8 20:57  embyserver-backup-full

Which to me at least seems correct

 

Is there any other configuration I'm missing?

[Lessaj 467]

Did you adjust the permissions recursively? What are the permissions on /mnt/stuff/Backup/Emby/embyserver-backup-full/data/library.db?

[Hsgnd 2]

8 hours ago, Lessaj said:

Did you adjust the permissions recursively? What are the permissions on /mnt/stuff/Backup/Emby/embyserver-backup-full/data/library.db?

Yes, I did run chown with the -R flag

 

Heres the permissions on the library.db file:

~ » ll /mnt/stuff/Backup/Emby/embyserver-backup-full/data/library.db
-rwxrwxr-x 1 doug stuffaccess 5.1M Sep  9 17:14 /mnt/stuff/Backup/Emby/embyserver-backup-full/data/library.db

 

[Lessaj 467]

Hm, well the backup folders should probably be owned by the emby user ID but with 775 permissions and being part of the stuffaccess group should really be sufficient...

[Hsgnd 2]

I'm trying some things out and I noticed that unmounting and mounting the drive with sudo mount -a makes emby able to write to the hard drive.

The journalctl logs:

~ » journalctl -xb | grep stuff
Sep 10 13:14:32 archlinux systemd[1]: Mounting /mnt/stuff...
░░ Subject: A start job for unit mnt-stuff.mount has begun execution
░░ A start job for unit mnt-stuff.mount has begun execution.
Sep 10 13:14:34 archlinux systemd[1]: Mounted /mnt/stuff.
░░ Subject: A start job for unit mnt-stuff.mount has finished successfully
░░ A start job for unit mnt-stuff.mount has finished successfully.
Sep 10 13:16:18 archlinux systemd[1]: mnt-stuff.mount: Deactivated successfully.
░░ The unit mnt-stuff.mount has successfully entered the 'dead' state.
Sep 10 13:16:18 archlinux systemd[1]: mnt-stuff.mount: Consumed 253ms CPU time, 120.6M memory peak.
░░ The unit mnt-stuff.mount completed and consumed the indicated resources.

[zerodayz 8]

I too see this behaviour; using a mounted drive, Emby can see it, and backup to it for a few days, then suddenly it decides that the FS it's been using for days is now RO or permission denied. 
Restarting the container resolves this. But is causing an issue, as for one instance I use the mounted drive for metadata, which, of course all randomly dies when it decides it can't see the mount any longer. 

Inspecting the mount from within the container, is fine, it CAN see it and write to it. Just Emby application decides it can't. 

There is nothing wrong with the mount from an OS point of view, it doesn't disconnect nor are there any permission issues. 

Would be great to get this resolved. 

[visproduction 315]

Since the OS works it seems like there could be an Emby code issue.  Maybe something about your server permissions could be tweaked a little better to solve it.

Have a look here: https://forums.linuxmint.com/viewtopic.php?t=235238

[Hsgnd 2]

So I ended up doing a fresh reinstall of arch and for some reason after reinstalling and re-configuring everything it finally worked.

I'll list the exact steps I did from a fresh install:

 

1. Install emby-server:

   sudo pacman -S emby-server

2. Start and enable the service:

   systemctl start emby-server.service
   systemctl enable emby-server.service

3. Create the group with permission for accessing the hard drive and add the users:

   sudo groupadd stuffaccess
   sudo usermod -aG doug stuffaccess
   sudo usermod -aG stuffaccess emby

4. Edited my /etc/fstab file to mount the hard drive with files on boot: (it only worked with ntfs3 as the file system. ntfs-3g did not work for me)

   # /dev/sda2
   UUID=D6C45D9BC45D7F25	/mnt/stuff	ntfs3		rw,uid=doug,gid=stuffaccess,nofail	0 2

5. Restart the system, access emby's dashboard and set the backup directory for as /mnt/stuff/Backup/Emby

And after restarting again and running the backup task it ran with no issues.

I have no clue why it was not working before. I had tested both ntfs3 and ntfs-3g on my fstab file and neither worked, but thankfully after reinstalling it's working again!

Thanks everyone for the replies!

[Luke 42077]

Thanks for following up with that !