Truy cập vào đường dẫn 'c: \ some \ path' bị từ chối đối với MSSQL CLR

Tôi nghĩ rằng đây là một vấn đề quyền, nhưng tôi gặp khó khăn trong việc định vị nó.

Tôi có một nhóm CLR trên một máy chủ (SQL Server 2016) và chúng hoạt động như bình thường. Tất cả đều được đánh dấu UNSAFE và chúng thực hiện nhiều loại tệp I / O khác nhau (đọc, viết, sao chép, di chuyển, đổi tên, v.v.). Tôi có thể chạy chúng thông qua SSMS hoặc từ một công việc dễ dàng như nhau.

Tôi cần cài đặt chúng trên một máy chủ khác (cũng là SQL Server 2016). Sử dụng Dự án Visual Studio ban đầu, tôi đã triển khai chúng đến máy chủ mới. Họ xuất hiện trong SSMS. Phần đó có vẻ tốt.

Khi tôi, từ SSMS, thử chạy một lỗi tôi gặp phải lỗi sau: "Truy cập vào đường dẫn 'bất kỳ đường dẫn nào tôi đi qua' đều bị từ chối."

Tôi đang đăng nhập vào SSMS dưới cửa sổ đăng nhập của tôi. Tôi có quyền truy cập vào cơ sở dữ liệu, tôi là dbo. Tôi là quản trị viên trên máy chủ. Tôi có quyền trong hệ thống tập tin.

Tôi có thể thiếu cái gì khác?

Tôi có quyền truy cập vào cơ sở dữ liệu, tôi là dbo. Tôi là quản trị viên trên máy chủ. Tôi có quyền trong hệ thống tập tin.

Không có vấn đề gì, điển hình. Trừ khi bạn (hoặc bất kỳ ai mã hóa các phương thức SQLCLR) thực hiện Mạo danh, thì bối cảnh bảo mật được sử dụng cho các hoạt động bên ngoài là của tài khoản dịch vụ chạy SQL Server (tương tự như xp_cmdshellhành vi). Đó là tài khoản cần sự cho phép đối với (các) đường dẫn mà bạn đang cố truy cập.

Để hoàn thiện về quyền truy cập tệp:

1. Đối với truy cập cục bộ (trên hộp), nó đơn giản như một trong hai
   1. tài khoản dịch vụ (hành vi mặc định) cho dịch vụ Công cụ cơ sở dữ liệu (nghĩa là MSSQLSERVER hoặc MSSQL $ InstanceName) cần sự cho phép, hoặc
   2. nếu mạo danh đã được thực hiện trong mã
      1. và một lần đăng nhập thực hiện mã là Windows Đăng nhập, không phải là một SQL Server đăng nhập, sau đó nó là rằng tài khoản Windows mà cần sự cho phép
      2. nhưng đăng nhập SQL Server đang được sử dụng, truy cập bên ngoài vẫn được thực hiện dưới dạng tài khoản dịch vụ Engine Engine
2. Để truy cập từ xa (ổ đĩa chung), có thể cần phải thiết lập ủy quyền bị ràng buộc (thông qua Active Directory; bao gồm SPN). Vấn đề double-hop Kerberos tốt. Trong trường hợp này, bạn sẽ thấy sự khác biệt giữa việc đăng nhập vào SQL Server từ một máy tính khác, ngoài máy chủ đang chạy so với đăng nhập trực tiếp vào máy chủ chạy SQL Server và sau đó kết nối với phiên bản SQL Server cục bộ.

Hãy nhớ rằng "DENY" được ưu tiên hơn "GRANT" (giống như với các quyền của SQL Server).

Để xác định xem tài khoản được sử dụng cho truy cập bên ngoài có thực sự có quyền cần thiết đối với (các) thư mục và / hoặc tệp hay không:

1. Chuyển đến "Thuộc tính" của đường dẫn được đề cập (tệp hoặc thư mục cụ thể báo cáo lỗi)
2. Chuyển đến tab "Bảo mật"
3. Nhấp vào nút "Nâng cao"
4. Chuyển đến tab "Truy cập hiệu quả"
5. Nhấp vào liên kết "chọn người dùng"
6. Nhập tên tài khoản đầy đủ (ví dụ NT Service\MSSQLSERVER)
7. Nhấp vào nút "OK"
8. Nhấp vào nút "Xem quyền truy cập hiệu quả"
9. Tài khoản đó có quyền truy cập vào tài nguyên đó không?

Có bất kỳ quyền DENY ở bất cứ đâu trong đường dẫn mà bạn đang cố gắng truy cập không?

CSONG Nếu tất cả các mã đang làm là công cụ hệ thống tệp, thì rất có thể bạn không cần phải có hội đồng được đánh dấu là UNSAFEvà thay vào đó nên như vậy EXTERNAL_ACCESS. Không có quá nhiều hoạt động hệ thống tập tin nên yêu cầu UNSAFE. Một trong số họ đang nhận được một danh sách các ổ đĩa cố định, nhưng không chắc chắn về những gì khác.

Đảm bảo tài khoản dịch vụ chạy máy chủ SQL có quyền truy cập vào các đường dẫn đó.

Đó sẽ là tài khoản thực sự tương tác với các tệp trên đĩa.

Trong trường hợp bạn đã làm tất cả các cách được đề cập ở trên, nhưng nó không hoạt động. Từ kinh nghiệm của tôi cho đến nay, bạn có thể thử mở SSMS với tư cách Quản trị viên .