Adding SMB / CIFS storage in Proxmox gives ' create storage failed: mkdir/pve/ddfw/images: Permission denied at /usr/share/perl5/PVE/Storage/Plugin.pm line 1374. (500) '
-
- gelöst
- neail
-
-
Solution -
This issue is happening as the Proxmox wants a writing privilege to every share folder, Make sure that READ/ WRITE access is given in 2 places in OMV
1. Users (2nd from last in the image)
2. Shared folders. (underlined)
(Group permissions are not necessary, just give user permissions (the blue key icon) & ACL(the blue checkbox icon))
Finally, Go to Services >> SMB/CIFS >> Shares >> select the appropriate share & edit >>> Tick the DOS attributes >> save (Scroll down) >>> confirm changes in Yellow bar (appearing at the top).
Finally, retry adding storage in proxmox. No error should occur.
Tips:
In proxmox sub folders can not be assigned from shares so it is advised to create a separate share in OMV and then grab from Prox.
- To add network shares to your VM/ container, use this command in prox shell-
- pct set 301 --mp1 /mnt/pve/nas,mp=/mnt/media
- Coloured sections are only to be changed
- 301 is the VM/CT number (use yours)
- (--mp1) = mount point, use different numbers like mp0, mp2, mp3 if you have multiple shares in same VM/CT, otherwise new one will remove older.
- use df -h command to know grabbed share mount location and put that into (/mnt/pve/nas)
- (mp=) mount point of VM/CT (recommending not changing, as in linux media directory is the default mounting location of external storage.)
-
KM0201
Hat das Thema freigeschaltet. -
Hey people, I am back again with the same issue in Proxmox 8.
This time, the error code is -
create storage failed: mkdir /mnt/pve/test/images: Permission denied at /usr/share/perl5/PVE/Storage/Plugin.pm line 1405. (500)The solution I found is to -
Selecting the content type, only the - VZdump backup file.
This solves the issue as the default Disk image content type, not sure about the cause, just make sure, you select only the VZdump.
Probably, in Proxmox 7 the default was VZDump and that's why I had missed that then. Fortunately it was default, otherwise it would had been hard to troubleshoot with 2 variables together.
Note - This is not an issue related to the user account of the SMB share, (i.e. with no write access). I have tried both write enabled and not enabled accounts , even in the example you can see, I am using the user_smb_omv, that is a read only, privilege. However, you should consider using a write enabled account if you want to reference this share to a container like Jellyfin, and store the metadata folder there.
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!