tar -C fails

tar -xf /mnt/user/appdata/gitlab/backups/repositories/xxx/xxx.bundle -C /mnt/user/appdata/gitlab/repositories/xxx/xxx.git

tar: ./hooks: Cannot utime: No such file or directory

tar: Exiting with failure status due to previous errors

works if I user disk1 or disk2 as a target, can't restore gitlab backup because of this. Using latest stable release

Anyone had this issue and knows workarounds / when this will be fixed?

Probably due to the links, a similar problem affects some docker containers.  You've found the workaround which is to use /mnt/diskx/ I'm not sure there will be a "fix"

which links? Can you point me to some docs or post?

is this unraid related or docker?

which links? Can you point me to some docs or post?

is this unraid related or docker?

The symlinking that occurs when Unraid aggregates the shares.  So /mnt/user/share = /mnt/disk1/share + /mnt/disk2/share + /mnt/disk3/share etc

It's Unraid related but also affects some docker containers if you try and use /mnt/user/appdata/app rather than /mnt/cache/appdata/app

so, there is no way for me to scale gitlab over more then 1 disk?

This sounds pretty major to me, sucks if the devs really won't work on this

so, there is no way for me to scale gitlab over more then 1 disk?

 

This sounds pretty major to me, sucks if the devs really won't work on this

Well I'm not sure anyone has tried scaling gitlab over multiple disks, and I'd always assumed it was a limitation of Linux and the app you use not supporting symlinks but I may be wrong.  Got to ask though, how big is your gitlab?! 

so, there is no way for me to scale gitlab over more then 1 disk?

 

This sounds pretty major to me, sucks if the devs really won't work on this

Just looked at the command you're running, if it's all in your appdata share, then that should be cache only, so why can't you use /mnt/cache/ instead of /mnt/user/ ?

not so big, only 15GB, it just feels like a step backwards if I move it to a disc and not a share.. specially since other apps also use that disk which may fill it up

In all honesty it's probably better off all on one disk anyway, saves spinning up all the drives over which you've spread the data if you're using only one disk. 

Just looked at the command you're running, if it's all in your appdata share, then that should be cache only, so why can't you use /mnt/cache/ instead of /mnt/user/ ?

My appdata is not cacheonly, which is not best-practice as it seems. I also have jira running on it and don't want to have all the files uploaded there on the cache (which may be worked around by adding an extra -v for the data in jira)

And just because you specify a disk doesn't mean it's not in a share.  My music is all on disk8 so I can access it via /mnt/disk8/music or /mnt/user/music 

Just looked at the command you're running, if it's all in your appdata share, then that should be cache only, so why can't you use /mnt/cache/ instead of /mnt/user/ ?

My appdata is not cacheonly, which is not best-practice as it seems. I also have jira running on it and don't want to have all the files uploaded there on the cache (which may be worked around by adding an extra -v for the data in jira)

Yeah, it's not a great idea for the reasons I've specified above.  It will break some containers.

as a software dev myself (with not a lot of filesystem knowledge) I just ask myself why they wrote this awesome filesystem if it doesn't work like a filesystem? kinda destroys the purpose in my opinion, but this might be a special case and only my opinion

as a software dev myself (with not a lot of filesystem knowledge) I just ask myself why they wrote this awesome filesystem if it doesn't work like a filesystem? kinda destroys the purpose in my opinion, but this might be a special case and only my opinion

Yeah, I'm just struggling to see the advantage of having the data spread over disks, so don't really see why it's a problem.  Also like I said earlier I'd always assumed it was a Linux problem rather than an Unraid specific issue myself.

as a software dev myself (with not a lot of filesystem knowledge) I just ask myself why they wrote this awesome filesystem if it doesn't work like a filesystem? kinda destroys the purpose in my opinion, but this might be a special case and only my opinion

It's my understanding that the User Share system (/mnt/user and /mnt/user0) is built on FUSE, uses it to build virtual file systems over the top of the disk file systems.  You may want to research how FUSE works.  It's probably why links can't work.