You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have an odd issue that I can't seem to resolve. I have a volume mapped to the CrashPlan container with full write access that is pointing to an SMB share folder. The folder is initially mapped on the host via /etc/fstab that is ignoring permissions and setting everything to 0750 permission.
Whenever I do a restore to this directory share from CrashPlan, it fails with permission denied. The odd thing is, when I execute a terminal into the running container as the same user of the one running CrashPlan, I can manually create, delete and modify files in that SMB share volume as expected, but for some reason CrashPlan cannot restore to it.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have an odd issue that I can't seem to resolve. I have a volume mapped to the CrashPlan container with full write access that is pointing to an SMB share folder. The folder is initially mapped on the host via
/etc/fstab
that is ignoring permissions and setting everything to0750
permission.Whenever I do a restore to this directory share from CrashPlan, it fails with permission denied. The odd thing is, when I execute a terminal into the running container as the same user of the one running CrashPlan, I can manually create, delete and modify files in that SMB share volume as expected, but for some reason CrashPlan cannot restore to it.
Any idea what could be wrong here?
Beta Was this translation helpful? Give feedback.
All reactions