I have urbackup running on docker in Debian lxc on proxmox.
I have two computers,
First is my windows pc which is having issues with being unable to backup as it fails everytime.
Second is a linux machine, which backups without issue.
Both backup to my proxmox server running on proxmox inside an lxc with docker.
The backup on Windows starts and I can see the backup directory filling up and the log shows files backing up correctly, but the end result is always a “failed” state.
The directory I’m trying to backup is
C:\Users\Username|Username
I have tried putting the following flags, but none of them resolves my issues
/follow_symlinks,symlinks_optional,share_hashes,optional
/symlinks_optional,share_hashes
/share_hashes
/symlinks_optional
This is the urbackup log:
urbackup.log (261.9 KB)
2023-09-30 17:52:28: ERROR: Creating symlink at "/backups/anex-pc/230930-1645/Anex/Application Data" to "Anex\AppData\Roaming" failed. Operation not supported (errorcode=95)
You seem to have figured out it is something about symlinks…
What filesystem are you using? Does it support symlinks?
You say your linux client backups just fine, so it should work with a windows client afaik, but I have to ask to rule it out. (I can’t find any reference to any other client in the log, but it’s pretty long so I might just miss it)
At the top in your logifle it says:
2023-09-28 18:07:15: ERROR: No permission to access "/backups/urbackup_tmp_files"
-----------------------------------
023-09-28 18:07:18: Reflink ioctl failed. errno=1
2023-09-28 18:07:18: WARNING: Syncing /backups/05b89714-7c4d-40fb-a908-e45f326c0624 failed. This may cause problems with backup consistency on disk. Operation not permitted (code: 1)
Are the credentials correct on the backup folder and is the filesystem 100% ok?
Well the logs do flag this in red that error creating symlink, so I was quite sure its symlink related.
My first solution was to disable symlink, which should be easy but its not I read the documentation and all it stated is how to set flag’s and what the defaults are, but no way how to disable it.
My next goto was going through the forum and searching for the solution, but I see that lots of people with this issue still have no resolution for over 3-4 years now. so that was a dissapointment.
Here, hoping mine would be different case (fingers crossed)
Now to answer to you queries:
- The file system is zfs from truenas as an cisf share with 777 permissions.
- I checked again and I do have symlinks in the backup from linux client
- I nuked my previous urbackup setup for a fresh install just to check and verify that my installation was ok, so i had not connected my other client to it yet.
Are the credentials correct on the backup folder and is the filesystem 100% ok?
I did not understand what you meant here, could you elaborate a bit please.
Note as i’m writing this:
I also have a suspicion that CIFS share may be the culprit here, as it may need some setting to work symlinks. but i do not know how to do that.
This is the fstab entry im using to mount the cifs share to proxmox
//192.168.100.205/truenas-data/backups /mnt/truenas/truenas-data/backups cifs _netdev,noserverino,x-systemd.automount,noatime,uid=100000,gid=100000,dir_mode=0777,file_mode=0777,credentials=/root/.smb,rw,iocharset=utf8,noperm 0 0
uid=100000 means root inside lxc
Nvm, I misread your log. But the credentials, well we get to that below…
AFAIK cifs can NOT create symlinks, or set credentials on files for that matter, the credentials are set at mount and can not be changed (but for the ACTUAL credentials on the files you have to check on the location where the file server resides). But then again, I have never ran truenas so maybe they have their own protocol that allows this and do not use samba?
And I have to mention… 777… should REALLY not be used, it is just one of those things you should avoid at all cost.
If you want to do stuff like that I would like to point you in the direction of NFS instead. But again, I do not know how truenas filesharing works.
Is this the reason you want to use hard-links instead of symlinks?
If you want to do stuff like that I would like to point you in the direction of NFS instead. But again, I do not know how truenas filesharing works.
I’m quite new to linux, I tried to mount nfs shares but it was too complicated for me at that time, then i tried CIFS Samba and it worked painlessly so I have stuck with it ever since, since it never gave me any issues.
Is this the reason you want to use hard-links instead of symlinks?
I just want the backup succed that is all, tbh i dont want the symlinks to be followed, but i cant disable that in urbackup or cant find how to achieve this. just not failing the full 40 gb done backup in the end because 1 symlink failed is dissapointing to me.
And I have to mention… 777… should REALLY not be used, it is just one of those things you should avoid at all cost.
does 660 work as a better alternative to 777, its just a separate datapool just for backups. Isolate from everything internet related.
Just so you understand, the symlink settings in the web gui is about the urbackup storage usage of symlinks. If your filesystem supports it I highly suggest using it.
Is THAT what the problem is for you, then use symlinks_optional on each directory you have broken symlinks on. Note that this also disables following symlinks (it’s a bit confusing, I know) so if you want that you also have to add follow_symlinks.
Example:
/home/username|home/symlinks_optional,follow_symlinks;/some/other/directory|other/symlinks_optional
“home” will not fail if symlinks are broken and symlinks WILL be followed and backed up.
“other” will not fail if symlinks are broken but will NOT follow and backup the symlinks.
https://www.urbackup.org/administration_manual.html#x1-640008.3.4
Can you explain your setup more clearly, because I can’t figure out what a cifs share has to do with anything related to urbackup.
Are you backing up TO a cifs share (the backup storage location is on a cifs share) or are you trying to backup a cifs share on your windows machine?
If it’s #1 I’m surprised it even works.
If it’s #2, why are you backing up the share and not the filesystem where the fileserver resides (ie a client on the system where the cifs server resides)?
Generally 644 for files and 755 for directories as max. but I usually go 640 and 750 (or even 600 and 700) because there is absolutely no reason to give “everybody” writing access to ANYTHING close to EVER (there can be exceptions, but they are extremely few).
The reason you end up in this situation is because you 1. use samba, 2. mount the cifs share as root.
Recommendation from me is to mount it as the user you will interact with it with 644 (if you are unsure how groups and stuff works on linux), root will ALWAYS have full access anyway, your user will have full access and any other user can READ files but not write.
Just so you understand, the symlink settings in the web GUI is about the urbackup storage usage of symlinks. If your filesystem supports it I highly suggest using it.
Noted, I’ll keep that in mind once I can get atleast 1 successful backup done.
Is THAT what the problem is for you, then use symlinks_optional
Sadly as i listed in the original post I have tried various combinations, including:
/follow_symlinks,symlinks_optional,share_hashes,optional
/symlinks_optional,share_hashes
/share_hashes
/symlinks_optional
and various others, all fail at the end
but I usually go 640 and 750
ok, ill set it to 640 as your logic makes sense to me.
It wont solve your problem. Also, the mounting has nothing to do with how the files are actually created on the physical drive, that is defined in your smb.conf (I think is the file, haven’t used samba for a while).
But just so you know, you can NEVER chown or chmod a mounted samba share, that has to be done on the system where the file server resides.
Not sure if you are unwilling or missing my question on WHERE the samba share comes into play with urbackup?
You don’t have to anwer if you dont want to, but to me it seems this can be one of the problems.
Then we have the issue of what user urbackup is running as, but I leave that be since you seem to be running everything as root. 
With truenas there’s no smb.conf , the settings are done through ui.
The share is then mounted in proxmox using fstab where the following line mounts it on the system
//192.168.100.205/truenas-data/backups /mnt/truenas/truenas-data/backups cifs _netdev,noserverino,x-systemd.automount,noatime,uid=100000,gid=100000,dir_mode=0777,file_mode=0777,credentials=/root/.smb,rw,iocharset=utf8,noperm 0 0
you can NEVER chown or chmod a mounted samba share
yes, the uid,gid options are defined during mounting and are unchangeable other than fstab.
Yeeeeah… And where do you think those ui changes gets saved? xD
Those are just fantasy gid and uid, ie, it is what you SEE on the side you mount it, they NEVER translate to the actual files. For all we know the files on the filsystem can be set to 700 owned by root, witch means nothing other than root can ever change them, but I don’t know because you don’t answer my question.
Good luck, since you don’t seem to want to answer my questions I sadly can’t help you.
First off thanks for your input, I would not have solved this issue without it.
Solution:
It was definitely an issue with how the CIFS share was mounted in fstab
the following flags were not even needed for this to work just the “mfsymlinks” during mounting is required. everything worked out of the box.
/follow_symlinks,symlinks_optional,share_hashes
You must have “mfsymlinks” in your mounting command for symlinks to work.
//192.168.100.205/truenas-data/backups /mnt/truenas/truenas-data/backups cifs _netdev,noserverino,x-systemd.automount,noatime,uid=100000,gid=100000,dir_mode=0640,file_mode=0640,credentials=/root/.smb,rw,iocharset=utf8,noperm,mfsymlinks 0 0
I have edited the topic and marked it solved for anyone later on who needs this.
1 Like
God job!!
A little info about what you are doing, just be mindful, its def not bullet proof…
Make sure you can actually restore the backups too.
A backup is not a backup until you have restored it. 
The mapping between a CIFS/NTFS ACL and POSIX file permission bits is imperfect and some ACL information may be lost in the translation.
mount.cifs(8) — cifs-utils — Debian stretch — Debian Manpages
Restored 38gb worth of files as a test, compared it to original, 1:1 copies, i’d say restoring works as intended.
1 Like
