[TUTORIAL] Tutorial: Unprivileged LXCs - Mount CIFS shares

barnfast said:
Thanks, op. This worked great.

Proxmox -> LXC Debian 13 running docker -> Immich container
The Immich container is using an encrypted smb-shared TrueNAS Scale dataset dedicated to Immich, with the Immich container as the only user with access.

Photos are backing up now. Looks like it worked. :)

One thing to note (thanks to Immich's docs!) is that I had to go to my NAS and set my ACL mode to Passthrough in my dataset. Before that, Immich would fail its startup checks and not load.
Click to expand...
I am doing the same with immich, but got a Problem. The share is accessible via cli and user root. But not with immich. No read permission. Can you give me a hint?
There is no user "immich" to authorize to tha share.
 
Henryyyy said:
I am doing the same with immich, but got a Problem. The share is accessible via cli and user root. But not with immich. No read permission. Can you give me a hint?
There is no user "immich" to authorize to tha share.
Click to expand...
Answering my own post..
The solution was to modificate the entry in fstab.
The share has to be mounted with
Code: 
uid=999,gid=991
 
Henryyyy said:
Answering my own post..
The solution was to modificate the entry in fstab.
The share has to be mounted with
Code: 
uid=999,gid=991
Click to expand...
I went a different route.

There is no user "immich" to authorize to tha share.
Click to expand...

I created user immich (uid 3003) on TrueNAS. I gave that user sole access to the Immich SMB share.

Then on Proxmox, my fstab has

Code: 
# Mount CIFS share on demand with rwx permissions for use in LXCs (manually added)
//192.168.[my_nas]/immich/ /mnt/lxc_shares/nas_immich_rwx cifs _netdev,x-systemd.automount,noatime,uid=100000,gid=110000,dir_mode=0770,file_mode=0770,user=immich,pass=[immich_user_login_on_truenas] 0 0

Immich docker runs as root on the LXC, which translates to uid 100000 on Proxmox host. The fstab converts that to the immich user on TrueNAS when accessing the share.
 
before everything worked. I don't know the cause but now with large files it gives me an error:

rsync error: error in file IO (code 11) at receiver.c(381) [receiver=3.4.1]
1.048.412.160 14% 23,96MB/s 0:04:03
rsync: [sender] write error: Broken pipe (32)

I the only one who has had this problem?
for small files it works The container has been upgraded to Debian 13
 
barnfast said:
It sounds like you’re running out of storage space.
Click to expand...

with df -h I see that I have 38gb free on the container and 1.7tb on the nas.

Code: 
df -h
File system                       Dim. Usati Dispon. Uso% Montato su
/dev/mapper/pve-vm--116--disk--2   49G  9,2G     38G  20% /
//192.168.1.18/jellyfin           3,6T  2,0T    1,7T  54% /mnt/jellyfin
none                              492K  4,0K    488K   1% /dev
udev                              7,8G     0    7,8G   0% /dev/tty
tmpfs                             7,8G     0    7,8G   0% /dev/shm
tmpfs                             3,2G  104K    3,2G   1% /run
tmpfs                             7,8G     0    7,8G   0% /tmp
tmpfs                             5,0M     0    5,0M   0% /run/lock
tmpfs                             1,6G  8,0K    1,6G   1% /run/user/1000
 
Last edited:
Henryyyy said:
I am doing the same with immich, but got a Problem. The share is accessible via cli and user root. But not with immich. No read permission. Can you give me a hint?
There is no user "immich" to authorize to tha share.
Click to expand...
Can you confirm that you have done these steps in the container?
created the group:
Code: 
sudo groupadd -g 10000 lxc_shares
Added to the group the user of immich:
Code: 
sudo usermod -aG lxc_shares immich_user
given permissions to the folder to use that group:
Code: 
sudo chown -R root:lxc_shares your_directory

I don't use IMMICH, and I've never configured it. so I can't help you any further.
 
worked fine for me, but I still have a problem and don´t know how to fix it

I run proxmox backup server as LXC on my proxmox ve setup

when I create a datastore on PBS, it is created and the process ends in OK status, but when I Access the datasore created, a error shows up

unable to open chunk store at "/mnt/nube/pbsdatastore/.chunks" - Permission denied (os error 13)

As I have read, the user backup is who manages the created datastore from now on though it was created by root with no problems.

So I can´t proceed unless I give the user backup permisssions to access the mount.

any suggestions?

just reading the above post, I solved this, thank you very much
 
Last edited:
gralf said:
worked fine for me, but I still have a problem and don´t know how to fix it

I run proxmox backup server as LXC on my proxmox ve setup

when I create a datastore on PBS, it is created and the process ends in OK status, but when I Access the datasore created, a error shows up

unable to open chunk store at "/mnt/nube/pbsdatastore/.chunks" - Permission denied (os error 13)

As I have read, the user backup is who manages the created datastore from now on though it was created by root with no problems.

So I can´t proceed unless I give the user backup permisssions to access the mount.
Click to expand...
Why don't you give the user these permissions? This should fix the issue.
BTW: I would reconsider using a smb mount as datastore they usually don't have great performance (if at all): https://forum.proxmox.com/threads/datastore-performance-tester-for-pbs.148694/

I also wouldn't use a PBS on the same server as your ProxmoxVE as sole backup. In case the server gets broken you won't be able to access your backups. You will need at least two other copies, e.G. on another Backupserver, an removable datastore (aka external USB disc) or a S3-Storage. Since the S3-Support is still technology preview I wouldn't relie on it as sole offsite backup either.
 
This guide worked well for me for about six months until one of my smb mounts had a problem.

I use hardlinks extensively. I ended up having errors involving them.

Code: 
dmesg | grep -i cifs | tail -n 50
<snip>
[  829.053758] CIFS: VFS: Autodisabling the use of server inode numbers on \\192.168.1.5\data
[  829.053763] CIFS: VFS: The server doesn't seem to support them properly or the files might be on different servers (DFS)
[  829.053764] CIFS: VFS: Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.

Despite all of my smb shares having exactly the same mount configuration, this one was the only one where the "serverino" flag was being disabled. I tried everything I could to get the serverino flag activated on this error-prone smb share and hardlinks working again.

The files on the smb share would have the correct inode value (passed through from TrueNAS), but the linkcount would be 1. For example, I had 18 copies of a file with inode value 43355. On TrueNAS's console those files would show as 18 links, but on the problematic smb share in Proxmox, they'd show as 18 files with inode 43355 while each having only 1 link. That was causing numerous errors in programs that were managing those hardlinked files.

After ruling out a number of causes, I suspect I was looking at an inode collision caused by a file on the smb share and a file on Proxmox having the same inode value. I was never able to confirm that though.

I ended up switching out the smb/cifs share for an nfs share of the same dataset and that seems to have fixed the problem. I used this guide as a basis to switch over. No more filesystem errors. No more hardlink problems.

I'm not sure how the inode problem started, nor sure how to prevent it from happening again on my other smb shares.
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back