Open daNutzzzzz opened 2 years ago
Whats happening with this?
If it can help, I tried to run radarr in a docker container too, which is hosted on a Synology DSM VM. I had two mount points, /config
(which is local to the VM) and /downloads
, which actually is a remote folder.
In radarr UI, under the System -> Status tab, I can see the /config
mount point (which is local), but not the /downloads
(which is a cifs mount point).
From within the docker container, I can actually navigate in /downloads
and see the folder, so it exists. This is my mount
output:
/dev/sdb1 on / type btrfs (rw,nodev,relatime,ssd,discard,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,syno_allocator,subvolid=552,subvol=/@syno/@docker/btrfs/s
ubvolumes/7cd48fb4de26a9ec78add52c59bc8dcd159c3c88c98b17c9368ca99b481ab5f6)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/synomonitor type cgroup (ro,nosuid,nodev,noexec,relatime,name=synomonitor)
cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpuacct)
cgroup on /sys/fs/cgroup/cpu type cgroup (ro,nosuid,nodev,noexec,relatime,cpu)
cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
\134\134192.168.42.25\134Downloads on /movies type cifs (rw,nodev,noexec,relatime,vers=3.02(syno),blocksend,sec=ntlmssp,cache=strict,username=harry,domain=WORKGROUP,uid=1026,
forceuid,gid=100,forcegid,addr=192.168.42.25,file_mode=0777,dir_mode=0777,iocharset=utf8,nocase,nounix,mapposix,rsize=1048576,wsize=1048576,actimeo=1)
\134\134192.168.42.25\134Downloads on /downloads type cifs (rw,nodev,noexec,relatime,vers=3.02(syno),blocksend,sec=ntlmssp,cache=strict,username=harry,domain=WORKGROUP,uid=10
26,forceuid,gid=100,forcegid,addr=192.168.42.25,file_mode=0777,dir_mode=0777,iocharset=utf8,nocase,nounix,mapposix,rsize=1048576,wsize=1048576,actimeo=1)
/dev/sdb1 on /config type btrfs (rw,nodev,relatime,ssd,discard,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,syno_allocator,subvolid=521,subvol=/@syno/docker/ra
darr/config)
/dev/sdb1 on /etc/resolv.conf type btrfs (rw,nodev,relatime,ssd,discard,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,syno_allocator,subvolid=257,subvol=/@syno/
@docker/containers/26df07f671f45d2415df76909d696ce344348506c454bce6fe4362f67c69d3e2/resolv.conf)
/dev/sdb1 on /etc/hostname type btrfs (rw,nodev,relatime,ssd,discard,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,syno_allocator,subvolid=257,subvol=/@syno/@do
cker/containers/26df07f671f45d2415df76909d696ce344348506c454bce6fe4362f67c69d3e2/hostname)
/dev/sdb1 on /etc/hosts type btrfs (rw,nodev,relatime,ssd,discard,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,syno_allocator,subvolid=257,subvol=/@syno/@docke
r/containers/26df07f671f45d2415df76909d696ce344348506c454bce6fe4362f67c69d3e2/hosts)
devpts on /dev/console type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
proc on /proc/bus type proc (ro,relatime)
proc on /proc/fs type proc (ro,relatime)
proc on /proc/irq type proc (ro,relatime)
proc on /proc/sys type proc (ro,relatime)
proc on /proc/sysrq-trigger type proc (ro,relatime)
tmpfs on /proc/acpi type tmpfs (ro,relatime)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/scsi type tmpfs (ro,relatime)
tmpfs on /sys/firmware type tmpfs (ro,relatime)
The important line is
\134\134192.168.42.25\134Downloads on /downloads type cifs (rw,nodev,noexec,relatime,vers=3.02(syno),blocksend,sec=ntlmssp,cache=strict,username=harry,domain=WORKGROUP,uid=1026,forceuid,gid=100,forcegid,addr=192.168.42.25,file_mode=0777,dir_mode=0777,iocharset=utf8,nocase,nounix,mapposix,rsize=1048576,wsize=1048576,actimeo=1)
Therefore, I have \\192.168.42.25\Downloads
mounted as downloads
, but radarr is not picking it.
This is the output of /api/v3/diskspace
(the API being called in the status page):
[
{
"path": "/",
"label": "",
"freeSpace": 72731815936,
"totalSpace": 74216005632
},
{
"path": "/config",
"label": "",
"freeSpace": 72731815936,
"totalSpace": 74216005632
}
]
My suspect is that the disk check logic is being too aggressive and mounted volumes are being ignored. Happy to help if you want me to try something, I'm not really using the container and I don't have any data at all inside.
I am having this EXACT same issue in Sonarr. When I console into the container I am able to see the mount and write to it without issue, but it's not showing in the Locations in the Web GUI.
I am having this EXACT same issue in Sonarr. When I console into the container I am able to see the mount and write to it without issue, but it's not showing in the Locations in the Web GUI.
Exactly the same issue I am having, and I want to say at one point it WAS showing in the UI, just not sure when it went away.
I had a very similar issue but with unionfs, I was mounting a read only nfs share with a rw nfs share overlayed and Sonarr/Radarr wouldn't acknowledge the folders existence, I removed "defaults" and set this as my options instead and it started working "cow,allow_other,nonempty" don't know if that will help with your samba mounts or not but thought I would share.
i'm having this issue as well. anyone have ideas on why it isn't shown?
after looking more into it...why not just do the below to make it consistent with Lidarr?
private IEnumerable<string> GetRootPaths()
{
return _rootFolderService.All()
.Select(x => x.Path)
.Where(path => path.IsPathValid(PathValidationType.CurrentOs) && _diskProvider.FolderExists(path))
.Distinct();
}
currently the https://github.com/Radarr/Radarr/blob/0361299a73ac1e24813e274ac69161a937b452b8/src/NzbDrone.Core/DiskSpace/DiskSpaceService.cs#L19 file has the following which is probably too restrictive
private IEnumerable<string> GetMoviesRootPaths()
{
// Get all movie paths and find the correct root folder for each. For each unique root folder path,
// ensure the path exists and get its path root and return all unique path roots.
return _movieService.AllMoviePaths()
.Where(s => s.Value.IsPathValid(PathValidationType.CurrentOs))
.Select(s => _rootFolderService.GetBestRootFolderPath(s.Value))
.Distinct()
.Where(r => _diskProvider.FolderExists(r))
.Select(r => _diskProvider.GetPathRoot(r))
.Distinct();
}
Is there an existing issue for this?
Current Behavior
System > Disk Space > Location does not show the docker volume that is mapped to the underlying host (ubuntu server) mount to a remote NAS CIFS share.
This is also not working in Sonarrv4 This is working correctly in Lidarr & Readarr
Expected Behavior
System > Disk Space > Location displays the volume and the space stats.
Steps To Reproduce
Environment
What branch are you running?
Master
Trace Logs?
radarr.debug.txt radarr.txt
AB#3773